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1  Overview 


This  document  is  the  final  report  for  DARPA  contract#  F30602-00-2-0503,  entitled  “Activelets: 
Light  Weight  Architectures  forSOF  Planning  and  Scheduling.”  As  part  of  the  Active  Templates 
program,  this  project  aimed  broadly  at  delivering  continuous  planning  and  scheduling  capabil¬ 
ities  to  support  crisis  response  for  Special  Operations  Forces.  The  principal  accomplishment 
of  this  effort  has  been  the  development  of  Comirem  (Continuous  Mixed-Initiative  REsource 
Management  tool),  an  interactive  planning/scheduling  system  designed  to  more  directly  match 
the  iterative,  user-centered  nature  of  planning  and  scheduling  in  practical  domains  by  providing 
the  means  to  represent  evolving  scenarios,  define  and  reuse  operational  templates,  maintain 
problem  consistency  in  response  to  execution  monitoring  and  information  updates,  and  detect 
inconsistencies  and  signal  appropriate  alerts  in  response.  This  report  describes  the  design  of 
Comirem  and  summarizes  the  capabilities  that  it  provides. 

A  significant  historical  limitation  of  planning  and  scheduling  technologies  is  that  they  tend 
to  be  designed  as  batch-oriented  solution  generators,  where  users  cannotdirectly  guide  solution 
development  and  attempt  to  achieve  desired  results  indirectly  by  manipulating  system  inputs. 
This  user-interaction  model  and  system  design  perspective  is  at  direct  odds  with  the  characteris¬ 
tics  of  most  practical  domains,  where  requirements,  capabilities  and  plans  evolve  incrementally 
and  in  parallel  overtime,  and  users  invariably  possess  knowledge  that  should  override  aspects  of 
system  models.  Furthermore,  the  need  for  reassessment  and  revision  continues  as  the  plan  is  ex¬ 
ecuted  and  results  deviate  from  expectations.  In  practice,  planning  and  resource  management  is 
fundamentally  an  iterative  process,  and  attempting  to  support  this  process  with  a  batch-oriented 
solver  results  in  an  awkward,  indirect  and  inherently  inefficient  problem-solving  cycle. 

Comirem  is  designed  from  an  alternative,  incremental  perspective.  It  promotes  a  graphi¬ 
cal,  spreadsheet-like  model  of  user-system  interaction,  wherein  resource  assignment  decisions 
can  be  constrained,  refined  and  revised  opportunistically  as  information  becomes  available,  as 
specific  planning  choices  become  apparent,  as  execution  results  dictate,  or  as  circumstances 
otherwise  warrant.  The  system  provides  a  range  of  support  for  a  user-driven  resource  manage¬ 
ment  process.  At  any  point  in  the  planning  process,  the  system  computes  and  maintains  a  basic 
set  of  resource  allocation  options  for  any  given  task  in  the  plan.  As  task  requirements  and  re¬ 
source  capabilities  are  adjusted,  or  as  specific  resource  assignments  are  made,  underlying  time 
and  resource  propagation  techniques  are  applied  to  update  the  feasible  options  for  other  tasks, 
to  identify  forced  decisions  and  to  detect  infeasible  solutions.  The  user  can  invoke  an  auto¬ 
mated  scheduling  capability  to  establish  overall  resource  feasibility  of  a  plan,  and  this  capability 
can  be  coupled  with  an  undo  mechanism  to  explore  the  consequences  of  various  requirement 
and/or  resource  availability  changes.  All  interaction  with  the  system  is  in  terms  of  a  high-level 
domain  model,  which  shields  the  user  from  the  details  of  the  system’s  underlying  search  model. 
Comirem  has  been  applied  initially  to  the  domain  ofSpecial  Operations  Forces  (SOF)  planning, 
where  the  use  of  transportation  assets,  taskforces  and  equipment  must  be  managed  over  time. 

The  Comirem  effort  descends  from  earlier  work  within  the  Intelligent  Coordination  and  Lo¬ 
gistics  Laboratory  in  the  Robotics  Institute  at  Carnegie  Mellon  University  involving  the  AMC 
Barrel  Allocator  [Becker  and  Smith,  2000],  a  tool  for  day-to-day  allocation  of  aircraft  and  air¬ 
crews  for  the  United  States  Air  Force  that  is  now  part  of  the  operational  planning  system  in 
the  Tanker/Airlift  Control  Center  at  the  USAF  Air  Mobility  Command.  Whereas  the  AMC  Barrel 
Allocator  focuses  on  large-scale  problems  with  more  narrowly  circumscribed  types  of  alloca- 


1 


tion  constraints,  Comirem  focuses  on  smaller-scale  but  more  ill-structured  types  of  allocation 
problems. 

The  design  of  the  Comirem  planner  reflects  several  basic  principles  that  we  believe  are  fun¬ 
damental  to  collaborative,  human-computer  interaction  in  practical  planning  domains: 

•  Adjustable  Decision-Making  Autonomy 

One  key  to  effective  collaborative  planning  is  a  decision-making  process  that  allows  the 
degree  of  automation  to  vary  according  to  problem  solving  context  and  user  preference. 
The  Comirem  planner  allows  the  user  to  inject  herself  into  the  decision-making  process  at 
different  levels  of  granularity.  At  the  lowest  level,  the  system  takes  responsibility  only  for 
proposing  and  implementing  resource  assignments  for  individual  elements  (or  activities) 
in  the  plan,  and  the  user  retains  control  over  resource  assignment  decisions.  However, 
even  in  this  (largely  manual)  mode  of  operation,  the  system  is  frequently  playing  a  quite 
substantial  role,  in  determining  the  consequences  of  all  relevant  constraints  on  user  allo¬ 
cation  decisions  (e.g.,  the  overall  duration  of  a  move,  given  that  multiple  trips  are  required 
and  aircrews  must  rest  during  the  course  of  the  move).  The  user  is  free  to  make  specific  ad¬ 
justments  to  an  activity’s  resource  requirements  (e.g.,  adding  another  aircraft  type  to  the 
set  of  possible  allocation  options)  or  to  override  specific  usage  constraints  (e.g.,  reduce 
computed  duration  constraints  due  to  knowledge  of  a  strong  tail  wind)  without  carrying 
along  and  anticipating  interactions  with  all  other  constraints.  In  other  decision  contexts 
the  user  can  delegate  increased  decision-making  scope  to  the  system.  The  user  may  choose 
to  manipulate  constraints  associated  with  larger  plan  fragments  (e.g.,  plan  threads),  and 
request  feasibility  checking  and/or  scheduling  in  response  to  assess  consequences.  At  the 
end  of  the  automation  continuum,  the  user  can  request  the  construction  of  a  fully  sourced 
plan,  in  which  case  the  system  constructs  a  schedule  according  to  user-specified  goals  and 
preferences.  Through  iterative  generation,  retraction  and  adjustment  of  (sets  of)  resource 
assignments,  system  planning  and  scheduling  processes  support  collaborative  reconcilia¬ 
tion  of  planning  objectives  and  desired  actions  with  available  resources. 

•  Translation  of  System  Models  and  Decisions 

A  second  key  to  effective  collaborative  planning  is  an  ability  on  the  part  of  the  system  to 
communicate  elements  of  its  internal  models  and  solutions  in  user-comprehensibleterms. 
In  Comirem,  this  is  accomplished  through  a  combination  of  graphical  visualization  and 
model-based  explanation  techniques.  Visual  displays  are  used  to  compactly  convey  vari¬ 
ous  decision  implications  (e.g.,  how  many  trips  are  required  if  this  type  of  transportation 
resource  is  used,  from  where  will  various  resources  be  sourced,  what  will  be  the  overall 
makespan  of  a  particular  movement  activity)  as  well  as  potentially  non-obvious  allocation 
constraints  (e.g.,  MOG  limitations).  In  other  advice-giving  contexts,  internal  system  repre¬ 
sentations  are  mapped  to  user-level  actions  through  the  use  of  abstract  domain  models. 
Comirem’s  higher-level  “activity-resource”  model  allows  the  system  to  impose  structure 
on  the  distance  constraints  involved  in  a  “cycle”  that  has  been  detected  in  the  temporal 
constraint  network  (i.e.,  characterizing  them  as  interdependent  sets  of  activity  durations, 
inter-activity  precedence  relations,  etc.).  This  structure  then  provides  the  basis  for  identi¬ 
fying  and  proposing  relevant,  user-level  constraint  relaxation  actions  that  make  sense  for 
resolving  the  conflict. 
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•  Incremental  Problem-Solving  Procedures 

A  third  key  to  effective  collaborative  planning  is  a  problem-solving  process  that  promotes 
incremental  decision  making.  In  complex,  ill-structured  planning  domains,  all  relevant 
constraints  are  generally  not  known  at  the  outset,  and  those  that  are  can  frequently 
change  as  planning  and  execution  progresses  over  time.  Hence,  planning  proceeds  with 
whatever  information  is  available,  decisions  are  made  on  the  basis  of  current  information, 
and  as  additional  information  becomes  known,  conflicting  decisions  are  appropriately 
revised.  Within  such  a  continuous  planning  process,  the  ability  to  maintain  a  sense  of 
problem-solving  continuity  to  the  user  is  crucial.  In  arriving  at  a  given  plan  or  schedule 
(either  partial  or  complete),  the  user  has  invested  time  and  energy  in  understanding,  as¬ 
sessing  and  validating  various  component  decisions.  The  introduction  of  new  or  changed 
constraints  should  not  arbitrarily  result  in  wholesale  changes  to  the  plan.  The  system 
should  instead  act  to  preserve  prior  decisions  wherever  possible  and  meaningful.  The 
Comirem  planning  framework  is  designed  generally  with  an  incremental,  change-based 
problem-solving  process  in  mind,  and  furthermore  allows  the  user  to  explicitly  manage 
the  scope  of  allowable  change  in  specific  decision  contexts. 

The  remainder  of  this  report  is  organized  as  follows: 

•  Section  2  provides  an  analysis  of  the  SOF  planning  domain,  highlighting  the  issues  that 
have  shaped  the  development  of  Comirem. 

•  Section  3  summarizes  the  basic  components  of  a  Comirem  domain  model,  including  rep¬ 
resentational  issues  and  the  conceptual  model,  and  describes  the  Comirem  scheduling 
engine  and  system  architecture. 

•  Section  4  describes  our  efforts  towards  integration  with  other  applications  in  the  SOF- 
Tools  environment. 

•  Section  5  presents  two  SOF-related  demonstration  problems  that  have  driven  both  the 
design,  implementation  and  evaluation  ofthe  Comirem  system. 

•  Finally,  in  Section  6,  we  discuss  some  potential  extensions  to  the  Comirem  system  and 
scheduling  model. 

•  Three  appendices  are  also  provided: 

-  Appendix  A  presents  a  full  description  ofthe  XML  specification  forall  Comirem  input 
data  files. 

-  Appendix  B  includes  a  user’s  manual  for  the  Comirem  web-browser-based  GUI. 

-  Appendix  C  presents  the  abstracts  of  all  research  publications  funded  under  this 
project. 
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2  Domain  Analysis 

The  current  focus  for  Comirem  is  the  Special  Operations  Forces  (SOF)  planning  domain,  which 
is  characterized  by  a  very  fine-grained  representation  of  activities  and  resources,  a  relatively  short 
temporal  horizon  (typically  a  number  of  hours  or  days),  and  a  highly  synchronized  environment 
where  multiple  mission  threads  must  be  coordinated  as  part  of  an  overall  mission  (e.g.,  air  sup¬ 
port  provided  for  the  duration  of  an  assault  on  a  target).  In  addition,  plans  and  schedules  in 
the  SOF  domain  must  be  developed  rapidly  on  the  basis  of  available  (and  often  incomplete) 
information  and  then  continually  refined  and  revised  as  new  information  is  accumulated  and 
execution  circumstances  necessitate  change.  Execution  typically  commences  before  planning  is 
complete  and  the  dynamic  nature  of  the  environment  requires  a  tight  coupling  between  exe¬ 
cution  and  (re)planning  processes.  Plans  inevitably  do  not  execute  as  expected,  so  there  is  a 
constant  need  to  be  able  to  quickly  identify  critical  constraints  and  decision  tradeoffs,  and  for 
rapid  evaluation  of  alternative  recovery  options.  The  problem  is  further  complicated  by  the  fact 
that  planning  often  takes  place  in  a  distributed  fashion,  by  mobile  decision-makers  with  limited 
computational  resources  and  under  executional  duress. 

Additional  features  related  to  the  flexible  nature  of  plans  in  the  SOF  domain  are  relevant  to 
the  design  of  Comirem: 

•  Activity  requirements  often  include  a  choice  of  multiple  resources  or  capabilities,  and  the 
selection  of  a  particular  resource  or  capability  may  impact  decisions  elsewhere  in  the  plan 
by  either  restricting  or  relaxing  remaining  scheduling  options. 

•  Resources  may  be  aggregated  and  disaggregated  over  time  as  a  means  of  grouping  per¬ 
sonnel  and  equipment  into  functional  teams  (e.g.,  taskforces). 

•  Resource  constraints  become  known  incrementally.  As  knowledge  ofthe  problem  domain 
develops  (e.g.,  the  status,  location  and  performance  characteristics  of  resources),  the  sys¬ 
tem  must  be  able  to  incorporate  and  adapt  to  changes  in  the  underlying  resource  model. 

•  Resources  may  themselves  be  treated  as  cargo  and  transported  by  other  resources,  en¬ 
abling  the  positioning  of  assets  throughout  the  theater. 

•  Certain  activities  (e.g.,  those  involving  the  sourcing  of  assets)  may  only  be  required  in 
specific  situations,  whereupon  their  durations  are  dictated  by  the  present  circumstances. 
These  derivative  activities  retain  zero  durations  when  not  required. 

•  An  activity’s  resource  requirements  may  warrant  multiple  trips  by  a  resource  or  resources 
to  perform  a  task  (e.g.,  the  transportation  of  troops  and  equipment).  Sibling  activities 
(i.e.,  clones)  are  instantiated  automatically  on  demand  to  represent  situations  where  the 
cargo  manifest  for  an  activity  exceeds  the  capacity  limits  of  a  single  resource. 

•  Sequences  of  activities  can  be  grouped  into  threads  and  assigned  resources  (e.g.,  task- 
forces)  collectively  to  better  reflect  SOF  mission-planning  approaches. 
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3  COM  I  REM  System  Overview 

Comirem  supports  both  incremental  and  automatic  scheduling  in  logistical  environments.  In 
this  section,  we  present  an  extensive  description  of  the  primary  features  and  components  of 
Comirem  that  contribute  to  delivering  its  various  scheduling  capabilities,  focusing  on  the  con¬ 
ceptual  model  for  representing  logistical  scheduling  domains,  the  flexible-time-bounds  sched¬ 
uler  and  mixed-initiative  techniques  for  resource  management.  The  overall  design  of  Comirem 
reflects  the  following  themes: 

•  Flexible  user  control  of  scheduling  automation: 

The  system  supports  both  incremental  (i.e.,  user-driven)  and  automatic  (i.e.,  system- 
driven)  commitment/decommitment  of  resources.  Allocation  options  are  continuously 
updated  by  the  system  to  reflect  the  current  state  of  decision-making  and  provide  an  up- 
to-date  assessment  of  resource  availability,  and  an  undo  mechanism  supports  a  what-if 
style  of  interaction  that  facilitates  consideration  of  alternative  task-allocation  decisions. 

•  Constraint  and  solution  visualization: 

To  provide  further  support  for  user  interaction,  the  Comirem  GUI  highlights  the  prop¬ 
agated  impact  of  constraint  tightening  and  relaxation  (e.g.,  owing  to  the  manipulation 
of  temporal  bounds)  and  changes  in  resource  availability  (e.g.,  owing  to  the  commit¬ 
ment/decommitment  of  resources).  A  spreadsheet  display  metaphor  is  utilized  through¬ 
out  to  provide  direct  access  to  relevant  problem  constraints  and  visualization  of  the  im¬ 
pact  of  their  modification. 

•  Tight  interplay  between  scheduling  and  planning  decisions: 

The  distinction  between  what  is  generally  thought  of  as  a  “scheduling”  decision  as  op¬ 
posed  to  a  “planning”  decision  is  becoming  increasingly  transparent.  Planning  decisions, 
like  howto  perform  a  task  (i.e.,  the  sequence  of  activities  required  to  achieve  its  implied  ob¬ 
jective),  are  directly  influenced  by  the  typical  scheduling  decisions  of  when  to  perform  a  task 
and  which  resource(s)  to  use,  and  vice  versa.  Comirem  relies  on  an  explicit  and  declarative 
domain  knowledge  base  to  make  all  relevant  information  available  to  the  user  and  the 
system  throughout  the  entire  problem-solving  process. 

•  Lightweight  component  capabilities: 

In  a  nod  to  the  more  lightweight  client/server  model,  Comirem  is  implemented  as  a  stand¬ 
alone  scheduling-engine  server  (written  in  Common  Lisp  [  teele  Jr.,  1990])  that  interacts 
with  an  independent  web-browser-based  GUI  client  to  deliver  incremental  and  automatic 
scheduling  capabilities  to  the  user  and  set  the  stage  for  possible  future  multi-user  interac¬ 
tion. 

•  Interoperability: 

The  use  ofXML  [Harold  and  Means,  2002]  as  the  input/output  data  specification  format 
facilitates  interoperability  with  a  wide  range  of  external/legacy  systems  and  provides  for 
an  open  and  explicit  specification  of  all  system  inputs  and  outputs  (i.e.,  at  the  level  of 
both  domain  definition  and  problem  description). 
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3.1  Representation  of  SOF  Domains 

Com i rem  allows  the  user  to  define  a  problem-solving  context  (called  a.  situation)  that  is  comprised 
of  descriptions  of  domain-specific  activities,  resources  and  capabilities.  These  descriptions  are 
built  upon  a  set  of  system- provided  situation-independent  primitives,  such  as  basic  move  and 
event  activities,  stationary  and  mobile  resources,  and  temporal  sequencing  constraints.  (These 
primitives  are  formally  introduced  in  the  following  section,  3.2:  Conceptual  Model.)  Situation 
descriptions  are  augmented  by  loading  in  one  or  more  plan  descriptions  (called  scenarios )  defin¬ 
ing  networks  of  activities  to  which  available  resources  must  be  assigned.  Scenarios  rely  on  the 
activity  types,  resource  types  and  instances,  and  capabilities  defined  within  the  currently  loaded 
situation.  This  separation  of  data  allows  the  user  to  establish  a  specific  context  within  which  an 
evolving  set  of  activities  is  to  be  scheduled.1 

For  example,  a  typical  military  situation  may  involve  resource  definitions  for  some  basic  he¬ 
licopter  types  (e.g.,  MH-47,  MH-60)  and  some  instances  of  those  types  (e.g.,  tail  numbers  MH-47- 
001,  MH-47-001,  MH-60-001)  initially  located  at  a  predefined  location  (e.g.,  BASE-ALPHA).  Each 
helicopter  type  provides  a  set  of  capabilities  (e.g.,  heavy-transport,  1  ight-transport)  that 
may  in  turn  be  required  by  typical  military  activities  (e.g.,  deploy-forces,  evacuate-forces). 
These  activity  types  may  further  include  detailed  descriptions  of  required  subactions,  such  as 
cargo  loading/unloading  steps  and  positioning/depositioning  legs  that  may  be  required  of  their 
assigned  resources. 

Given  the  situation  described  above,  the  stage  is  now  set  to  define  a  rescue  plan  involving 
instances  of  the  deploy-forces  and  evacuate-forces  activity  types  that  relies  on  the  three 
helicopters  available  at  BASE-ALPHA  to  deploy  forces  and  perform  a  rescue  and  evacuation  mis¬ 
sion  to/from  some  designated  location  (e.g.,  embassy).  After  loading  both  the  situation  and 
scenario  (the  latter  of  which  identifies  the  necessary  plan-specific  deployment/  rescue  locations 
such  as  embassy),  Comirem  can  be  used  to  determine  the  feasibility  of  the  plan  given  its  various 
requirements  and  constraints  and  the  available  resources,  keeping  in  mind  that  additional  plans 
may  have  already  been  loaded  and  scheduled  within  this  same  situation. 

A  Comirem  situation  description  includes  the  following  pieces  of  information: 


•  activity  type  definitions:  descriptions  (i.e.,  attributes  and  their  default  values)  of  activity 
classes  available  for  constructing  a  plan  (e.g.,  move-cargo,  airdrop-forces,  fighter- 
escort) 

•  resource  type  definitions:  descriptions  (i.e.,  attributes  and  their  default  values)  of  all  available 
resource  classes  (e.g.,  F-16,  B-2,  MH-60) 

•  model  type  definitions:  hierarchical  classifications  of  resource  types  relevant  to  a  particular 
domain  (e.g.,  ROTOR  and  FIXED-WING  for  aircraft,  WHEELED  and  TRACKED  for  vehicles)  that 
encapsulate  common  constraints  and  capabilities 

1 0nly  a  single  situation  may  be  in  effect  (i.e.,  loaded)  at  any  point  in  time;  loading  a  situation  erases  any  existing 
information  about  activity  types,  resources  types  and  instances,  and  capabilities.  Scenarios,  on  the  other  hand,  are 
cumulative:  that  is,  multiple  plans  can  be  loaded  into  a  single  situation  to  represent  multiple  demands  (i.e.,  sets  of 
activities)  to  be  scheduled.  (The  exception  is  that  once  loaded,  plan  files  cannot  be  reloaded  into  a  situation.) 
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•  capabilities:  descriptions  of  capabilities  (e.g.,  heavy-transport,  light-transport)  sup¬ 
ported  by  resources  and  required  by  activities  (to  provide  high-level  links  between  activities 
and  resources) 

•  resource  instances:  descriptions  (i.e.,  sets  of  attribute/value  pairs)  of  all  resources  available 
in  a  particular  situation  (e.g.,  MH-47-001,  MH-47-002)2 

Once  a  situation  has  been  loaded  into  Comirem,  any  number  of  scenarios  may  be  loaded  and 
then  scheduled  using  the  various  type  and  instance  definitions  made  available  by  the  situation. 
A  scenario  description  includes  the  following  pieces  of  information: 

•  plan  configuration:  description  of  a  plan  (e.g.,  its  temporal  horizon  and  granularity,  release 
and  due  dates,  etc.) 

•  activity  instances:  descriptions  (i.e.,  sets  of  attribute/value  pairs)  of  the  activities  that  com¬ 
prise  a  plan 

•  constraint  instances:  descriptions  (i.e.,  sets  of  attribute/value  pairs)  of  the  constraints  gov¬ 
erning  the  temporal  sequencing  of  activities  in  a  plan3 

•  place  instances:  descriptions  (i.e.,  sets  of  attribute/value  pairs)  of  the  places  specific  to  a 
plan  (e.g.,  locations  referenced  by  the  plan’s  activities) 

Figure  1  identifies  the  grouping  of  problem  structure  and  data  information  into  situation 
and  scenario  files  and  specifies  the  order  in  which  these  files  are  loaded  into  Comirem. 

3.2  Conceptual  Model 

The  underlying  scheduling  domain  model  in  Comirem  is  based  on  the  Ozone  schedulingdomain  on¬ 
tology  [Smith  and  Becker,  1997],  which  allows  a  user-interpretable  description  of  an  application 
domain  to  be  mapped  to  application  system  functionalities.  Problems  are  expressed  in  terms  of 
activities,  resources  and  constraints.  An  activity  requires  the  use  of  one  or  more  resources  for  some 
period  of  time  to  perform  a  designated  task.  Both  activities  and  resources  are  governed  by  a 
set  of  constraints,  which  impose  restrictions  on  when  activities  can  execute,  what  resources  can 
be  assigned,  and  when  resources  are  available  for  assignment.  In  the  following  subsections,  we 
present  these  basic  representational  entities  in  further  detail. 

Additionally,  Comirem  supports  the  use  of  capabilities,  which  are  objects  for  defining  an  in¬ 
direct  mapping  between  an  activity  and  its  required  resource(s).  Capability-based  resource  re¬ 
quirements  permit  the  user  to  specify  activity  needs  from  an  activity-based  perspective  and  avoid 
having  to  assemble  an  individual  set  of  resource  types  for  each  activity  by  hand. 

Figure  2  illustrates  the  various  relationships  that  can  be  defined  in  Comirem  among  activ¬ 
ities,  resources  and  capabilities,  to  facilitate  a  range  of  mappings  between  activities  and  their 
required  resources.  Using  the  more  traditional  approach,  activities— both  types  and  instances, 

2The  set  of  available  resource  instances  in  a  situation  is  often  referred  to  as  the  “bed-down”  information. 

3At  the  present  time,  Comirem  does  not  support  user-definable  constraint  types.  The  set  of  available  constraint 
types  is  described  in  Section  3.2.3  (Constraints). 
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Situation  Data 
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Figure  1:  Comirem  input  data  sources 


can  be  linked  directly  to  a  set  of  resources  identified  by  either  type,  instance  or  model.  Addi¬ 
tionally,  capabilities  can  be  included  in  this  mapping  by  allowing  activities  (again,  both  types 
and  instances)  to  refer  to  required  capabilities,  which  can  in  turn  be  linked  to  the  resources  that 
may  satisfy  their  requirements  (by  type,  instance  or  model).  Finally,  resources  can  also  be  linked 
to  capabilities  to  signal  their  ability  to  deliver  particular  capabilities  depending  on  how  they  are 
configured.4 

In  the  remainder  of  this  section,  we  introduce  the  primary  components  of  the  Comirem  con¬ 
ceptual  model:  activities  (Section  3.2.1 ),  resources  (Section  3.2.2),  constraints  (Section  3.2.3), 
capabilities  (Section  3.2.4)  and  plans  (Section  3.2.5). 

3.2.1  Activities 

Comirem  provides  two  basic  activity  types,  one  for  representing  moves  from  one  location  to  an¬ 
other  (typically  achieved  using  one  or  more  mobile  resources)  and  another  for  representing  events 
taking  place  at  a  single  location  (and  possibly  requiring  one  or  more  stationary  or  mobile  re¬ 
sources).  Both  of  these  activity  types  are  illustrated  in  Figure  3.  A  third  activity  type,  called  a 
wrapper,  provides  a  mechanism  for  enveloping  other  activities  as  in  a  parent-child  relationship 
(with  optional  siblings)  to  represent  hierarchical  activity  networks.  A  wrapper  is  an  abstract 
activity  whose  semantics  is  more  aptly  defined  by  that  of  its  constituent  activities.5 

Activities  may  impose  a  number  of  resource  allocation  constraints: 

•  capability/resource  requirements  designate  the  set  of  resources  that  might  alternatively  be 
used  to  support  the  activity,  expressed  either  in  terms  of  high-level  capabilities  (e.g.,  1  i  ght- 

4Resources  refer  to  capabilities  by  means  of  a  configuration  mechanism  that  facilitates  the  representation  of  dy¬ 
namically  configurable  resources  that  can  be  modified  to  deliver  different  capabilities  over  time.  The  configuration 
mechanism  is  described  in  Section  3.2.2. 

sThe  concept  of  a  wrapper  activity  is  discussed  in  greater  detail  in  Section  3.2.1 .1 . 
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Arcs  are  annotated  with  a  link  type  (in  boldface)  and  a  destination  object  type. 


Figure  2:  Comirem  conceptual  model  showing  links  between  capabilities,  resources  (types  & 
instances),  resource  model  types,  and  activities  (types  &  instances) 


transport,  close-ai  r-support),  specific  resource  types  (e.g.,  MH-47,  C-130,  HMMWV,  MK-V) 
or  resource  model  types  identifying  relevant  predefined  resource  classes  (e.g.,  ROTOR,  FIXED- 
WING,  WHEELED,  TRACKED),  and  can  optionally  dictate  the  exact  number  of  resource  in¬ 
stances  required 

•  a  duration,  specified  either  as  a  range,  a  single  fixed  time  value,  or  as  a  function  of  speed 
and  distance  (in  the  case  of  moves)  that  dictates  how  long  the  activity  will  take 

•  a  manifest,  specified  in  terms  of  common  cargo  and  passenger  types  and  quantities,  indi¬ 
cating  the  capacity  requirement  of  the  activity 

Absent  an  explicit  designation  of  the  number  of  resources  required  by  an  activity,  the  man¬ 
ifest  is  matched  against  the  feasible  configurations  of  a  candidate  resource  to  determine  the 


Figure  3:  Move  and  event  activity  types 
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exact  number  of  resource  instances  required  to  perform  the  activity. 


3.2.1 .1  Hierarchical  Activity  Networks 

A  given  input  activity  may  expand  into  a  hierarchy  of  subactivities.  For  example,  a  move  in¬ 
volving  an  aircraft  may  be  comprised  of  positioning  and  depositioning  legs,  cargo-loading  and 
unloading  steps,  and  the  actual  flight  leg  between  the  origin  and  destination,  all  of  which  must 
be  temporally  synchronized.  Activities  with  subactivities  are  referred  to  as  aggregate  activities  and 
maybe  based  on  any  of  the  Comirem  activity  types:  namely  move,  event  or  wrapper.  Comirem 
provides  the  means  for  specifying  the  expansion  of  an  aggregate  activity  into  a  network  of  syn¬ 
chronized  subactivities,  with  each  subactivity  possibly  specifying  its  own  requirements  and  im¬ 
posing  its  own  resource  usage  constraints,  as  illustrated  in  Figure  4. 


Figure  4:  Aggregate  activity  type  examples  (RESOURCE-SOURCING  and  MOVE-CARGO) 

The  activity  network  hierarchy  in  Figure  4  defines  three  levels  of  abstraction  for  the  move¬ 
ment  of  cargo  using  a  mobile  resource.  At  the  top  level,  the  resource  must  be  sourced,  or  posi¬ 
tioned,  from  a  previous  location  and  then  delivered  (or  returned,  as  in  the  case  of  a  round-trip 
reservation)  to  a  subsequent  location  (note  that  one  or  both  of  these  may  be  empty  if  the  re¬ 
source  is  already  located  at  its  designated  origin  or  will  be  left  at  its  designated  destination). 
The  RESOURCE-SOURCING  aggregate  activity  identifies  the  overall  extent  during  which  a  mobile 
resource  must  be  reserved  to  perform  its  required  tasks,  including  the  positioning  and  depo¬ 
sitioning  and  the  actual  cargo  movement.  The  intermediate  level  shows  the  separation  of  the 
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(de)positioning  legs  from  the  actual  cargo-movement  activity,  MOVE-CARGO,  which  is  itself  an 
aggregate  move  activity.  At  the  bottom  level,  the  MOVE-CARGO  activity  expands  into  three  ba¬ 
sic  steps:  a  cargo-loading  event  that  allocates  time  for  cargo  to  be  loaded  onto  the  mobile 
resource,  the  actual  move  activity  during  which  the  cargo  will  be  transported,  and  the  final 
cargo-unloading  event.  At  the  bottom  of  Figure  4,  note  that  the  location  of  a  mobile  resource 
assigned  to  the  RESOURCE-SOURCING  activity  is  tracked  overtime,  in  conjunction  with  the  leaf 
nodes  in  the  activity  network. 

The  specification  of  activity  networks  in  Comirem  relies  on  the  concept  of  an  anchor,  or 
nexus  activity,  which  identifies  the  level  of  detail  at  which  a  network  of  activities  is  defined  within 
a  plan.  The  nexus  activity  is  the  activity  within  a  hierarchical  activity  network  (as  shown  in 
Figure  4)  from  which  the  entire  (local)  network  is  derived,  in  both  an  upward  and  downward 
direction.  It  provides  a  convenient  handle  to  the  activity  network  that  can  be  easily  referenced 
by  other  activities  within  a  plan,  and  thereby  helps  to  collectively  define  the  level  at  which  an 
entire  plan  is  most  appropriately  viewed. 

For  example,  the  activity  network  in  Figure  4  is  arguably  most  logically  anchored  by  the 
MOVE-CARGO  activity,  because  it  identifies  the  logical  scope  for  a  cargo-movement  activity  in  a 
typical  logistical  plan.  From  the  perspective  of  the  planner,  the  movement  of  cargo  from  one 
location  to  another  represents  a  primary  action  in  such  a  plan.  The  sourcing  of  the  mobile 
resources  used  to  move  the  cargo  is  a  supporting  action  that  can  effectively  be  handled  in  the 
background.  Synchronization  among  activities  in  a  plan  will  most  likely  be  specified  in  terms  of 
cargo  movements,  ignoring  any  potential  supporting  (de)positioning  legs  that  may  need  to  be 
instantiated  to  facilitate  them. 

Given  this  view,  the  (de)positioning  legs  surrounding  the  MOVE-CARGO  activity  can  be  viewed 
as  providing  a  wrapper  around  the  activity  that  defines  the  necessary  positioning  activities  of  any 
mobile  resource  secured  for  the  task.  Figure  5  illustrates  the  recursive  expansion  of  a  nexus 
activity  both  downward  into  child  subactivities  and  upward  into  wrapper  activities.  Note  that 
any  activity  within  an  expanding  activity  network,  be  it  derived  as  a  child  or  wrapper  activity,  may 
itselffurther  expand  into  child  orwrapper  activities.  Returning  again  to  Figure4  and  usingMOVE- 
CARGO  as  the  nexus  activity,  it  should  be  evident  that  the  RESOURCE-SOURCING  aggregate  activity 
is  instantiated  as  a  wrapper  around  MOVE-CARGO,  with  the  POSITIONING  and  DEPOSITIONING 
moves  as  its  children,  and  that  the  LOAD,  TRANSPORT  and  UNLOAD  events  are  instantiated  as  the 
direct  children  of  the  MOVE-CARGO  aggregate  activity. 

One  additional  definition  is  appropriate  at  this  point.  We  use  the  term  derivative  to  describe 
an  optional  activity  (i.e.,  an  activity  whose  duration  may  be  zero).  Positioning  legs  for  mobile 
resources  are  the  most  obvious  derivative  activities.  If  a  mobile  resource  is  required  to  be  at  a 
specific  location  to  load  cargo  for  transport  and  is  already  collocated  with  the  cargo,  then  the 
duration  of  a  positioning  leg  to  get  it  from  its  current  location  to  the  location  of  the  cargo  is 
zero,  and  the  activity  is  therefore  a  no-op.  It  only  warrants  a  non-zero  duration  if  the  resource 
must  move  between  distinct  locations,  in  which  case  the  duration  is  dependent  on  its  speed  and 
the  necessary  travel  distance.6 

Comirem  relies  on  variables  within  activity  networks  to  both  retain  and  convey  values  across 
individual  activities.  Variable  values  are  stored  in  class  slots  in  activity  instances  and  passed  to 
child  and  wrapper  activities  during  activity  network  instantiation.  Two  typical  variables  used  to 

6AII  distances  in  Comirem  are  derived  using  a  Great  Circle  calculation. 
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Plan  Specification  Level 


Wrapper  Activities 


mvuKC 


wrappers 


NEXUS 

ACTIVITY 


Figure  5:  Instantiation  of  wrapper  and  child  activities  from  a  nexus  activity 


support  mobile  resource  sourcing  are  resource-origin  and  resource-destination.  These 
variables  allow  the  planner  to  indicate  a  specific  location  from  which  to  secure  a  resource  and 
a  specific  location  to  which  it  should  be  returned  following  its  use,  by  passing  their  values  to 
relevant  supporting  move  activities.  To  define  round-trip  sourcing,  the  resource-origin  and 
resource-destination  variables  are  simply  set  to  the  same  location.  In  a  more  flexible  plan, 
where  the  sourcing  locations  of  resources  may  not  be  specified,  these  variables  can  be  initialized 
as  free  variables,  thereby  allowing  the  scheduler  to  control  their  assignment  in  the  process  of 
considering  alternative  resource  options.  Resources  can  therefore  be  obtained  from,  and  re¬ 
turned  to,  any  location(s)  that  can  be  reached  in  the  amount  of  time  that  is  available  both  prior 
to,  and  following,  the  activity  in  question.7 

To  further  illustrate  the  concept  of  activities  in  Comirem,  we  provide  (in  the  following  three 
figures)  annotated  snapshots  of  XML  data  files  that  demonstrate  how  some  of  the  entities 
we  have  addressed  in  this  section  can  be  specified.  Figure  6  presents  the  definition  for  the 
RESOURCE-SOURCING  aggregate  wrapper  activity.  Figure  7  presents  the  definition  for  the  MOVE- 
CARGO  aggregate  activity  that  references  the  RESOURCE-SOURCING  wrapper.  Both  of  these  defini¬ 
tions  belong  in  the  situation-types  .xml  datafile.  Finally,  Figure  8  demonstrates  how  an  instance 
of  a  predefined  activity  type  is  specified,  in  this  case  by  referencing  the  MOVE-CARGO  activity.  This 


7The  process  of  binding  free  variables  is  described  in  detail  in  Section  3. 2. 1.4. 
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definition  belongs  in  the  scenario-^  an .  xml  datafile.8 

In  Figure  6,  the  RESOURCE-SOURCING  wrapper  adds  positioning  and  depositioning  move  ac¬ 
tivities  around  an  invoking  child  activity  (e.g.,  MOVE-CARGO  from  Figure  4)  in  a  directly  abutting 
sequence  and  passes  along  the  necessary  variable  values  (i.e.,  resource-origin,  resource- 
destination,  origin  and  destination)  to  help  in  determining  required  travel  distances.  The 
distinction  between  <variables>  and  <inputs>  is  that  variables  lacking  values  at  instantiation 
time  are  considered  free,  while  inputs  must  be  provided  by  the  invoking  activity.  Because  this  ac¬ 
tivity  is  intended  to  be  applicable  to  a  wide  range  of  resource  types,  requirements  for  the  specific 
mobile  resource(s)  to  be  sourced  are  specified  with  the  invoking  child  activity  instance,  in  which 
case,  as  a  result  of  this  wrapper,  the  necessary  time  block  for  the  reservation(s)  will  include  the 
(de)positioning  legs. 


Declare  the  variables  to  be 
maintained  by  the  activity: 

Declare  the  variables  required 
from  the  invoking  child  activity: 


Define  the  decomposition  of  an 
activity  into  subactivities  and 
specify  how  values  are  passed 
down  from  parent  to  child.  The 
i  ni  targ  forms  specify  how  values 
are  assigned  to  subactivity 
variables.  For  example,  the 
origin  and  destination  of  the 
positioning  move  are  assigned 
the  resource-sourcing  activity's 
resource-origin  and  origin  slot 
values,  respectively): 


Define  the  temporal  sequencing 
of  subactivities  fichiid  refers  to 
the  subactivity  that  invoked  the 
wrapper).  The  default  lower 
bound  for  successor  constraints 
is  0  minutes,so  the  additional 
zero-duration  upper  bounds 
indicate  that  these  activities  must 
abut  one  another: 


<type> 

<wrapper  name="resource-sourcing"> 


<vari abl es> resource-origin  resou rce-desti nati onc/vari abl  es> 


ci  nputs>or7'g7/7  desti nati on</i  nputs> 


<decomposition> 

cchi ld-spec  name=" positioning" > 
ctype- ref>move</type- ref> 
ci nitargs> 

<initarg  name=,,or7g7n"> 

<slot> resou rce-origi n</slot> 
c/i nitarg> 

ci ni targ  name=" desti nati on"> 
<keyword>or7g7A7</keyword> 

</i nitarg> 

</i ni targs> 

</child-spec> 

<chi ld-spec  name=" deposit ioning”> 
ctype- ref>move</type- ref> 

<i ni targs> 

cinitarg  name="or7g7/7"> 

<keyword>c/est7nat7on</keyword> 
c/i ni targ> 

<i nitarg  name=" desti nati on"> 

<slot> resou rce-desti nati onc/slot> 
</i ni targ> 

</i ni targs> 

</child-spec> 

</decomposi ti on> 


cconstrai nts> 
cconstrai nt> 

<type-ref>successor</type-ref> 

<f rom>pos 7 t ion ing</f r om> 

<to>: child</to> 

cubxi  ntervalxmi  nutes>0</mi  nutesx/i  ntervalx/ub> 
</constrai nt> 
cconstrai nt> 

ctype-ref>successorc/type-ref> 
cf rom> : chi 1 dc/f rom> 
cto>  depos 7 1 7  on i ng< / 1 o> 

cub>ci nterval>cmi nutes>Oc/mi nutes>c/i nterval>c/ub> 
c/constrai nt> 
c/constrai nts> 


c/wrapper> 

c/type> 


Figure  6:  Annotated  XML  specification  for  the  RESOURCE-SOURCING  wrapper  activity  type 


8While  the  RESOURCE-SOURCING  aggregate  activity  is  not  currently  part  of  the  Comirem  activity  type  library,  it  is 
a  logical  candidate  for  a  SOF-specific  activity-type  library,  as  we  discuss  in  Section  6.1.1  ( Plug-In  Domain  Models). 
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In  Figure  7,  the  MOVE-CARGO  aggregate  activity  is  defined  as  a  move  activity  that  expands 
both  downward  and  upward  to  generate  the  activity  network  shown  in  Figure  4.  It  decomposes 
into  three  subactivities  (of  predefined  types  not  shown)  that  divide  the  overall  cargo-movement 
action  into  separate  loading,  transporting  and  unloading  activities.  It  invokes  the  RESOURCE- 
SOURCING  wrapper  to  provide  the  necessary  (de)positioning  legs,  and  passes  on  the  necessary 
resource-origin,  resource-destination,  origin  and  destination  variable  values  to  help 
determine  the  required  travel  distances  for  those  moves.  The  former  two  variables  are  defined  as 
inputs  to  be  specified  with  an  instance  of  this  type  (or  left  unspecified  to  signify  free  variables), 
while  the  latter  two  reference  the  standard  move  slots.  As  in  the  previous  example,  there  are 
no  resource  requirements  specified  with  this  type  definition,  so  that  it  may  be  used  to  define  a 
variety  of  cargo-movement  activities.  The  requirements  instead  should  come  from  the  instance 
definition  that  references  this  activity  type  (see  Figure  8). 

Finally,  in  Figure  8,  an  instance  of  the  MOVE-CARGO  activity  type  is  defined  to  move  120  pas¬ 
sengers  (PAX)  from  home-station  to  staging-area.  Two  aspects  of  this  definition  are  worth 
highlighting: 

1.  Values  forthe  resource-origin  and  resource-destination  variables  maintained  by  the 
MOVE-CARGO  move  activity  and  RESOURCE-SOURCING  wrapper  activity  are  specified  explic¬ 
itly  using  i  ni  targ  tags,  thereby  requiring  that  any  resource  allocated  to  perform  this  task 
must  be  located  initially  at  home-station  (thus  eliminating  the  need  for  a  positioning 
leg)  and  then  returned  to  home-station  as  part  of  the  unsourcing  actions  (i.e.,  the  de¬ 
positioning  leg).  If  not  specified,  the  scheduler  is  free  to  secure  a  mobile  resource  from 
any  location— as  long  as  it  can  be  sourced  to  home-station  within  the  available  time 
window— and  to  leave  the  resource  at  the  destination  of  the  cargo  move,  namely  stagi  ng- 
area. 

2.  The  resource  requirements  for  this  activity  instance  are  specified  in  terms  of  a  capability, 
namely  1  i  ght-transport,  indicating  that  the  scheduler  is  free  to  consider  any  available 
resource  belonging  to  a  class  defined  as  capable  of  performing  a  light-transport  kind 
of  task.9 


9Comirem  treats  requi  rement  entries  as  parallel  resource  requirements,  meaning  that  additional  resources  must 
be  secured  for  the  same  time  period— i.e.,  the  scope  of  the  requirement  (in  this  case,  the  position-for-insertion 
activity).  Note  that  additional  actions  specified  by  wrapper  activities  (such  as  sourcing  moves)  may  result— 
legitimately— in  different  overall  reservation  durations. 
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<type> 

<move  name="move-cargo,,> 

ueciare  me  vanauies  m  ue 
maintained  by  the  activity: 

<vari abl  es>resource-ori gi n  resource-desti natiorK/vari  abl  es> 

Define  the  decomposition  of  an 
activity  into  subactivities  and 
specify  how  values  are  passed 
down  from  parent  to  child.  The 
initarg  forms  without  slot 
attributes  (i.e.,in  the  transport 
subactivity)  indicate  that  values 
are  assigned  to  the  subactivity's 
variables  using  the  identically 
named  variables  of  the  parent: 

<decomposi tion> 

<chi ld-spec> 

<type-  ref>  7oac/</type-  re  f  > 

<i ni targs> 

<initarg  name="pl ace"> 

<slot>ori gi n</slot> 

</i ni targ> 

</i ni targs> 

</chi 1 d-spec> 

<chi ld-spec> 

<type- ref> transport</ type- ref> 

<i ni targs> 

<i  ni  targxsl  ot>ori  gi  n</s1  otx/i  ni  targ> 

<i  ni  targxsl  ot>desti  nati  on</sl  otx/i  ni  targ> 

</i ni targs> 

</chi 1 d-spec> 

<chi ld-spec> 

<type-  ref>w/77oac/</type-  ref> 

<i ni targs> 

<initarg  name="pl ace"> 

<sl ot>desti nati on</sl ot> 

</i ni targ> 

</i ni targs> 

</chi 1 d-spec> 

</decomposi ti on> 

Define  the  temporal  sequencing 
of  subactivities: 

<constrai nts> 

<constrai nt> 

<type-ref>successor</type-ref> 

<f rom-type> load</f rom- type> 

<to-type>tra/isport</to-type> 

<ubxi  ntervalxmi  nutes>0</mi  nutesx/i  ntervalx/ub> 
</constrai nt> 

<constrai nt> 

<type-ref>successor</type-ref> 

<f  rom-type>tra#7sport</f  rom-type> 
<to-type>wn7oac/</to-type> 

<ubxi  ntervalxmi  nutes>0</mi  nutesx/i  ntervalx/ub> 
</constrai nt> 

</constrai nts> 

Define  the  wrapper  activities 
invoked  by  an  activity  and 
specify  how  values  are  passed 
up  from  child  to  (wrapper) 
parent: 

<wrappers> 

<wrappe r  name=" resource-sourcing"> 

<i ni targs> 

<i  ni  targxsl  ot>ori  gi  n</sl  otx/i  ni  targ> 

<i  ni  targxsl  ot>desti  nati  on</sl  otx/i  ni  targ> 

<i ni targ> 

<sl  ot> resource-origi n</ si  ot> 

</i ni targ> 

<i ni targ> 

<slot> resource-desti nati on</slot> 

</i ni targ> 

</i ni targs> 

</wrapper> 

</wrappers> 

</move> 

</type> 

Figure  7:  Annotated  XML  specification  for  the  MOVE-CARGO  activity  type 
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<i nstance> 

<acti vi ty  name="posi tion-for-insertion"> 

muiccuc  uic  type  ui  aiuvuy  tu 

instantiate: 

<type- ref>move-cargo</type- ref> 

Provide  initial  slot  values  for 
the  activity: 

<description>position  insertion  teams  at  staging  area</descri pti on> 
<ori gi n>home-stati on</ori  gi  n> 

<desti nati on>stagi ng-area</desti  nati  on> 

Provide  initial  slot  values  for 
the  attributes  of  any  derived 
activities  (i.e.,  from  either 
wrappers  or  subactivities): 

<i ni targs> 

<i ni targ  name=" resou rce-ori gi n"> 

<val ue>home-stati on</val  ue> 

</i nitarg> 

<i ni targ  name=" resou rce-desti nation"> 

<val ue>home-stati on</val ue> 

</i ni targ> 

</i nitargs> 

Specify  the  resource 
requirements  for  the  activity 
(in  this  case,  via  a  capability): 

crequi rements> 

<requi rement> 

<capabi 1 i ti es>l i ght-transport</capabi 1 i ti es> 

</requi rement> 

</requi rements> 

Specify  the  manifest  for  the 
activity: 

<mani fest> 

<mani fest-entry> 

<cargo  count="120">PAX</cargo> 

</mani fest-entry> 

</mani fest> 

</acti vi ty> 

</i nstance> 

Figure  8:  Annotated  XML  specification  of  a  MOVE-CARGO  activity  instance 


3. 2.1. 2  Activity  Attributes 

Activity  attributes  can  be  specified  at  either  the  class  or  instance  level,  depending  on  the  pref¬ 
erences  of  the  domain  modeler  and  the  nature  of  the  domain.  Class  attributes  define  a  default 
value  for  all  class  instances,  while  instance  attributes  permit  an  instance  to  override  a  class-level 
default  with  its  own  value.  A  typical  example  of  this  issue  involves  the  speed  of  a  resource.  A  par¬ 
ticular  type  of  resource  (e.g.,  MH-60)  may  have  a  standard  average  traveling  speed  of  177  mph, 
while  a  particular  MH-60  instance  (e.g.,  MH-60-001)  may  have  been  altered  to  increase  its  aver¬ 
age  traveling  speed  to  200  mph.  By  specifying  a  speed  attribute  with  a  value  of  177  mph  in  the 
MH-60  resource-class  definition  form,  all  MH-60  instances  will— by  default— inherit  the  177  mph 
average  traveling  speed  value.  In  the  case  of  MH-60-001,  specifying  a  speed  attribute  with  a 
value  of  200  mph  in  its  instance  definition  form  will  allow  it  to  override  the  default  177  mph 
value  with  its  own  individual  200  mph  value. 

In  the  activity  attribute  tables  that  follow  (Tables  1  and  2),  the  various  activity  attributes  are 
classified  according  to  how  they  are  generally  specified.  But  note  that  in  practice  they  could  be 
specified  at  either  the  class  or  instance  level.  Note  also  that  the  attributes  in  these  tables  follow 
the  XML  grammars  described  in  Section  A. 2. 
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Table  1 :  Activity  type  attributes 


•  Name 

The  name  of  the  activity  type 

•  Variables 


[required] 


[optional] 

The  variables  maintained  by  an  activity,  typically  for  use  in  informing  the  duration- 
calculation  process  (e.g.,  for  dealing  with  mobile-resource  positioning) 

For  wrappers,  variable  values  are  provided  by  the  invoking  activity;  otherwise,  they 
are  provided  by  the  activity  instance.  If  left  unspecified,  they  are  considered  free. 

•  Inputs  [optional] 

The  variables  to  be  initialized  at  instantiation  time  by  an  activity  instance 

•  Description  [optional] 

A  description  of  the  activity 

•  Decomposition  [optional] 

A  template  that  defines  how  an  activity  is  expanded  into  constituent  subactivities 

•  Constraints  [optional] 

The  temporal  sequencing  constraints  that  govern  any  constituent  subactivities 

Within  this  specification,  a  special  :  chi  Id  variable  can  be  used  to  reference  the 
invoking  activity  during  instantiation. 

•  Wrappers  [optional] 

The  wrapper-activity  types  to  be  invoked  during  instantiation 

•  Requirements  [optional] 

Specifies  the  resources  or  capabilities  required  by  an  activity 

•  Derivative-p  [optional] 

A  flag  indicating  whether  or  not  the  activity  type  is  derivative  in  nature  (i.e.,  its 
instances  only  become  necessary  as  the  result  of  some  other  scheduling  decision, 
as  with  a  (de)positioning  leg  for  a  mobile  resource)  The  default  is  nil. 

•  Capability-Type  [optional] 

Indicates  what  kind  of  capabilities  are  appropriate  for  this  activity  (i.e.,  move  or 
event)  The  default  is  obtained  from  the  activity’s  base  type. 

This  value  is  generally  only  overridden  in  special  cases  (e.g.,  when  a  mobile  re¬ 
source  is  required  by  an  event,  in  which  case  move-specific  capabilities  may  be 
more  appropriate) 
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Table  2:  Activity  instance  attributes 


•  Name 

[required] 

The  name  of  the  activity 

•  Type-Ref 

[required] 

The  type  of  the  activity:  either  move,  event  or  wrapper,  ora  user- 

defined  activity 

type 

•  Display-Name 

[optional] 

A  presentable  print-name  for  the  activity  (for  use  in  the  GUI) 

•  Origin 

[required] 

For  moves,  indicates  the  origin  location 

•  Destination 

[required] 

For  moves,  indicates  the  destination  location 

•  Place 

[required] 

Forevents,  indicates  the  location  at  which  the  event  takes  place 

•  Initargs 

[optional] 

A  collection  of  keyword-value  pair  specifications  for  passing  values 

either  down  to 

subactivities,  or  up  to  wrappers,  at  the  point  of  instantiation 

•  Manifest 

[optional] 

Describes  the  cargo  associated  with  an  activity,  in  terms  of  predefined  cargo  types 

(e.g.,  PAX  (personnel),  MUNITIONS,  PALLETS,  FUEL,  AIRCRAFT) 

•  Duration 

[optional] 

The  duration  of  an  activity,  specified  as  either  a  minimum,  maximum,  min/max 

pair,  or  fixed  value 

•  Time-Bounds-Constraints 

[optional] 

Specifies  (1 )  any  earliest/latest  start/finish-time  anchoring  constraints  (e.g.,  EST, 

LST,  EFT,  LFT)  on  an  activity  using  fixed  temporal  values,  and  (2)  the  ref-hours  to 

which  an  activity  may  be  linked,  by  either  its  start  or  finish  time,  or 

both 
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3. 2.1. 3  Sibling  Activities 

It  is  often  the  case  that  an  activity  requires  more  than  a  single  resource  instance— or  collection 
of  single  resource  instances— to  complete  its  desired  task,  generally  depending  on  the  size  and 
nature  of  its  manifest.10  For  example,  consider  that  an  activity  responsible  for  moving  person¬ 
nel  from  one  location  to  another  and  requiring  instances  of  the  MH-60  helicopter  class  needs 
enough  MH-60  instances  to  accommodate  the  number  of  personnel  involved  (according  to  the 
activity’s  manifest).  In  these  cases,  Comirem  uses  sibling  activities  to  ensure  that  the  proper 
number  of  resource  instances  are  allocated  to  an  activity.  A  sibling  is  a  clone  of  an  original 
nexus  (i.e.,  plan-level)  activity— and  its  fully  expanded  network  of  wrapper  and  child  activities, 
which  helps  transform  a  single  activity,  in  a  copy-and-paste  fashion,  into  a  series  of  multiple  iden¬ 
tical  and  possibly  parallel  activities,  each  requiring  a  single  resource  instance  (or  set  of  resource 
instances). 

Owing  to  their  support  of  flexible  decision-making,  siblings  are  ephemeral  in  nature,  lasting 
only  for  as  long  as  the  planner/user  stays  with  a  particular  resource  requirement  and/or  manifest 
configuration,  or  actual  resource  assignment.11  If  either  of  an  activity’s  requirements  or  manifest 
are  changed  at  any  time,  then  the  number  of  siblings  required  by  that  activity  may  also  change 
in  response. 

In  Figure  9,  a  fragment  of  a  typical  plan  is  presented.  Prior  to  scheduling,  Activity  A3  requires 
some  number  of  instances  of  the  MH-60  helicopter  class  to  handle  48  PAX  (personnel).  At  the 


Figure  9:  Fragment  of  a  plan  network  (prior  to  sibling  creation) 

point  when  the  scheduler  begins  allocating  resources  to  Activity  A3,  it  first  determines,  based 
on  its  knowledge  of  the  capacity  of  the  relevant  MH-60  configuration  required  for  this  task  (i.e., 
24  PAX),  that  two  MH-60s  are  needed.  This  determination  process  is  illustrated  in  Figure  10. 
A  single  sibling  activity  network  is  then  instantiated  and  spliced  into  the  network,  as  shown  in 
Figure  11  (the  sibling  and  new  temporal  sequencing  constraints  are  highlighted  in  red).  If  an 

10Recall  that  the  planner  may  also  declare  exactly  how  many  instances  of  a  resource  are  required  by  an  activity, 
thereby  overriding  the  manifest-based  calculation. 

"in  keeping  with  this  fact,  the  Comirem  GUI  will  display  siblings— only  if  they  are  scheduled  at  times  different 
from  their  original  activities— but  they  cannot  be  directly  manipulated  by  the  user.  If  a  sibling  is  selected  in  the  GUI, 
Comirem  will  treat  it  as  a  selection  of  the  original  activity. 
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assignment  of  MH-60s  is  made  at  this  point,  the  overall  plan  network  will  stay  in  this  state  until 
the  allocation  is  changed.  If  an  assignment  is  not  made,  the  sibling  will  be  removed  and  deleted, 
and  the  network  will  return  to  its  original  state. 


DEPLOY  to  AIRPORT  activity  instance  definition: 

<mani fest> 

<mani fest-entry> 

<cargo  count="256">PAX</cargo> 

</mani fest-entry> 

</mani fest> 

<requi rements> 

<requi rement> 

<capabi 1 i ti es>ai r-drop</capabi 1 i ti es> 
</requi rement> 

</requi rements> 


MH-60  resource  class  definition: 

<configurations> 

configuration  name=": default"  op="or"> 
<cargo  max="92">PAX</cargo> 

<cargo  max="5">PALLETS</cargo> 
</configuration> 

configuration  name="heavy- transport's 
<cargo  max="92">PAX</cargo> 
</configuration> 

configuration  name="ai r-drop"> 

<cargo  max="64">PAX</cargo> 

</conf i gu  rati on> 

</conf i gu  rati ons> 


DEPLOY  to 
AIRPORT 

DEPLOY  to 
AIRPORT 

DEPLOY  to 
AIRPORT 

DEPLOY  to 
AIRPORT 

DEPLOY  to 
AIRPORT 

move 

move 

move 

move 

move 

Original: 

manifest: 256  PAX 


Original:  Sibling  #1:  Sibling  #2:  Sibling  #3: 

manifest:  64  PAX  manifest:  64  PAX  manifest:  64  PAX  manifest:  64  PAX 


Figure  10:  Sibling  requirement  calculation  using  manifest  quantity  and  resource  configuration 
information 

Note  that  while  the  splicing  ofsiblings  is  done  in  a  manner  that  facilitates  parallel  processing 
of  the  original  activity  and  its  siblings,  parallelism  is  not  guaranteed.  If  only  a  single  resource  is 
available  (e.g.,  MH-60-001  in  the  case  above),  then  the  original  activity  and  its  sibling  will  have  to 
be  performed  in  sequence.  Figure  12  illustrates  the  case  involving  an  activity  and  three  siblings 
scheduled  on  either  one,  two,  three  or  four  resources.  A  strict  sequential  ordering  results  from 
the  one-resource  case  ([a]),  while  complete  parallelism  is  achieved  when  four  resource  instances 
are  available  ([d]). 

Finally,  there  are  some  conceptual  limitations  on  siblings  that  are  worth  noting: 

•  The  current  model  assumes  that  the  changing  of  a  resource’s  configuration  is  a  zero- 
duration  setup  operation.12  This  is  because  the  scheduler  looks  to  the  resource  class 
to  assess  the  capacity  of  a  resource  in  a  particular  configuration  instead  of  checking  the 
configuration  of  each  individual  candidate  resource  at  the  time  it  is  expected  to  be  used. 

•  Siblings  inherit  the  identical  resource  requirements  from  their  original  activity  and  must  all 
be  scheduled  using  the  same  specification  (though  not  the  same  instance(s)).  For  exam¬ 
ple,  if  the  user  selects  the  AC-130H  aircraft  type  for  an  activity  from  among  a  list  of  possible 
aircraft  types,  and  the  scheduler  determines  that  three  AC-130H  aircraft  instances  are  re¬ 
quired  to  perform  the  task,  then  each  of  the  original  activity  and  its  two  siblings  must 
be  assigned  a  single  AC-130H  aircraft  instance  (i.e.,  there  can  be  no  mix-and-match  making 

12To  be  more  precise,  Comirem  resources  currently  do  not  change  their  configuration  over  time,  although  this 
capability  is  envisioned  (and  partially  supported). 


20 


Implicit 
A3  resource 
requirement 
&  manifest 
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Original  plus  Sibling  Activity 
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A3-S1  resource 
requirement 
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ACTIVITY 
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successor 
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ACTIVITY 

A5 


1xMH-60 
24  PAX 


Modeling  assumption: 

MH-60  capacity:  24  PAX 


Figure  11:  Fragment  of  a  plan  network  following  the  instantiation  of  sibling  activities 


use  of  other  possible  required  resources).  This  is  because  siblings  are  instantiated  and 
scheduled  by  the  scheduler  in  the  same  step  as  their  original  activity,  and  only  a  single  cal¬ 
culation  is  performed  to  determine  the  required  number  of  siblings  based  on  a  particular 
resource  type  that  applies  to  all  activities  (original  and  siblings)  at  the  same  time. 

By  extension,  this  limitation  also  applies  to  the  case  where  multiple  resources  are  required 
for  an  activity  by  virtue  of  wrapper  or  child  activities  that  may  add  their  own  individual 
resource  requirements  to  those  of  the  nexus  activity.  In  these  cases,  the  scheduler  creates 
a  single  collective  resource  requirement  at  the  outset  of  the  scheduling  step,  determines 
the  number  of  siblings  required,  and  uses  the  same  resource  set  for  each  activity  network 
anchored  by  the  original  and  its  siblings. 

•  Related  to  the  previous  item,  activities  and  their  siblings  also  require  that  sourced  mo¬ 
bile  resources  (i.e.,  those  requiring  (de)positioning  legs)  report  from  and  return  to  the 
same  location  as  specified  by  the  original  activity  instance.  This  means  that  there  is  no 
optimization  done  to  minimize  the  use  of  extraneous  positioning  legs. 

Note  that  this  is  not  the  case  when  specific  sourcing  locations,  such  as  the  resource- 
origin  and  resource-destination  variables  mentioned  earlier,  are  unspecified  (i.e., 
free). 
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Figure  12:  Sequencing  possibilities  for  sibling  activities:  example  scenario  consisting  of  three 
siblings  and  an  original  activity  scheduled  on  one,  two,  three  and  four  resources 
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3. 2.1.4  Resource  Installation 


To  maintain  flexibility  in  the  evolving  plan  network  throughout  the  resource-allocation  process, 
Comirem  implements  a  least-commitment,  flexible  time-bounds  scheduling  approach  that  de¬ 
lays  the  refinement  of  task  durations  for  as  long  as  possible  and  avoids  completely  a  strict  tem¬ 
poral  sequencing  of  resource  assignments  (this  latter  process  is  described  in  Section  3.3).  In  this 
section,  we  focus  on  the  former  process,  which  we  refer  to  as  resource  installation,  and  describe 
its  purpose,  its  behavior,  and  its  implications. 

Because  Comirem  supports  the  specification  of  multiple  resource-requirement  options  for 
a  single  activity,  and  because  the  duration  of  an  activity  may  depend  on  the  particular  char¬ 
acteristics  of  the  resource  allocated  to  it  (owing  to  either  the  speed  of  the  resource  or  some 
other  relevant  performance  attributes),  Comirem  needs  a  mechanism  for  tightening  its  under¬ 
lying  plan  representation  when  a  scheduling  decision  is  made  that  narrows  the  field  of  feasible 
candidates— and  therefore  more  accurately  assesses  the  temporal  requirements— foran  activity. 

As  an  example,  consider  a  logistical  environment  that  involves  the  movement  of  cargo  from 
location  to  location,  with  the  possibility  of  using  multiple  types  of  mobile  resources  for  the 
movement  activities.  The  duration  of  each  movement  is  a  factor  of  (1 )  the  distance  to  be  trav¬ 
eled  from  origin  to  destination  and  (2)  the  speed  of  the  mobile  resource  assigned  to  perform 
the  task.  At  first,  the  duration  of  each  such  movement  activity  A  is  a  range  of  the  form:  [lb(A), 
ub(A)],  where  lb(A)  is  the  speed  of  the  fastest  candidate  resource  type  and  ub(A)  is  the  speed  of 
the  slowest  candidate  resource  type  for  activity  A.  It  is  not  until  the  point  at  which  the  scheduler 
allocates  a  specific  resource  instance  to  a  movement  task  that  its  duration  converges  on  a  fixed 
value  D(A)  :  lb(A)  <  D(A)  <  ub(A),  determined  by  the  speed  of  the  selected  resource  and  the 
travel  distance  required.  Once  D(A)  has  been  determined,  the  duration  of  the  movement  task 
can  be  fixed  and  the  network  can  be  tightened  to  reflect  the  assignment.  (But  note  that  this 
fixed -duration  activity  can  still  float  within  its  possibly  flexible  time  bounds,  depending  on  the 
available  slack  in  its  own  plan.) 

Whenever  a  specific  resource  candidate  is  considered  for  an  activity,  either  as  part  of  the 
process  of  determining  feasible  scheduling  options  or  performing  an  allocation,  Comirem  must 
first  install  the  resource  on  the  activity  to  understand  the  exact  temporal  requirements  of  the 
activity  when  paired  with  the  resource  in  question.  The  basic  installation  process  is  summarized 
in  Table  3. 

Figure  13  presents  a  graphical  summary  of  an  example  situation  existing  prior  to  resource 
installation  when  there  is  a  choice  between  two  resource  types  to  perform  a  typical  activity,  and 
Figure  14  illustrates  the  possible  outcomes  of  the  resource-installation  process  depending  on 
which  resource  type  is  chosen.  Referring  to  Figure  13,  notice  that  there  are  MH-60  helicopters 
located  at  Resource  Location  1,  and  MH-47  helicopters  located  at  Resource  Location  2. 
The  activity  to  which  one  of  these  resource  types  must  be  assigned  is  a  roundtrip  move  from 
the  Staging  Area  to  the  Enemy  Base,  with  book-ended  positioning  and  depositioning  legs  to 
source  the  aircraft.  If  the  MH-60  resource  is  chosen,  the  resources  will  be  sourced  from  and  re¬ 
turned  to  Resource  Location  1.  If  the  MH-47  resource  is  chosen,  the  resources  will  be  sourced 
from  and  returned  to  Resource  Location  2.  The  actual  required  duration  of  the  movement 
activity  is  either  175  minutes  using  the  MH-60  resource  to  travel  537.5  miles  at  184  mph,  or  212 
minutes  using  the  MH-47  resource  to  travel  625  miles  at  177  mph. 

Referring  now  to  Figure  14,  notice  the  state  ofthe  movement  activity  prior  to  resource  instal- 
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Table  3:  Resource  installation  process  description 


Operation-lnstall-Resources: 

With  resource  as  input: 

[1  ]  Bind  free  variables 

[2]  Call  Operation-lnstall-Resources  recursively  on  all  subactivities: 

For  each  leaf-level  subactivity, 

[a]  Cache  existing  temporal  bounds 

[b]  Calculate  and  assert  new  temporal  bounds 

given  resource  and  all  relevant  free  variable  bindings 

[c]  Check  network  consistency 

[i]  In  case  of  inconsistency,  undo  all  changes  and  throw  a  failure 

[ii]  Otherwise,  return  success 

[3]  If  a  failure  is  caught,  undo  all  changes  and  throw  a  failure 
Otherwise,  return  success 


lation.  Based  on  the  two  resource  options,  the  move  will  take  either  65  or  68  minutes,  and  the 
(de)positioning  legs  are  empty.  Following  the  installation  of  the  MH-60  resource,  whereupon  the 
Resource  Origin  and  Resource  Destination  variables  are  bound  to  Resource  Location  1, 
the  exact  temporal  requirement  for  the  activity  and  its  (de)positioning  legs  is  shown  in  Case  1 . 
Following  the  installation  of  the  MH-47  resource,  with  the  Resource  Origin  and  Resource 
Destination  variables  bound  to  Resource  Location  2,  the  exact  temporal  requirement  for 
the  activity  and  its  (de)positioning  legs  is  shown  in  Case  2. 

As  long  as  a  resource  is  installed  on  an  activity,  whether  or  not  it  is  allocated  to  that  activity, 
the  temporal  constraints  it  imposes  on  the  network  remain  in  effect.  Only  after  uninstalling 
the  resource— a  process  that  reverses  the  actions  of  the  installation  by  restoring  the  cached 
original  temporal  bounds  for  all  affected  activities— is  the  original  temporal  flexibility  of  the 
activity  restored  to  the  network. 
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Resource  sourcing  options  for  MOVE(Staging  Area  to  Enemy  Base): 

•  MH-60  from  Resource  Location  1 

•  MH-47  from  Resource  Location  2 


Figure  13:  Resource  installation  example:  a  scenario 
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Free  Variables: 

•  Resource  Origin 

•  Resource  Destination 


Resource  Origin:  [unbound], 
Resource  Destination:  [unbound] 


Prior  to  resource  installation: 

(candidate  resources:  MH-47  &  MH-60) 

MOVE 

Duration:  [65..68] 

[Case  1  ] 

Resource  Origin:  Resource  Location  1,  Resource  Destination:  Resource  Location  1 

Following  installation  of 

POS 

MOVE 

DEPOSITIONING 

MH-60  at  Resource  Location  1: 

20 

65 

90 

[Case  2] 

Resource  Origin:  Resource  Location  2,  Resource  Destination:  Resource  Location  2 

Following  installation  of 

MH-47  at  Resource  Location  2: 

POSITIONING 

MOVE 

DEPOSITIONING 

MH-60 

timeline 


MH-47 

timeline 


42 


68 


102 


All  times  are  in  minutes 


Figure  14:  Resource  installation  example:  temporal  implications  of  two  resource  alternatives 
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3. 2.1. 5  Threads 


The  remaining  activity  network  structure  provided  by  Comirem  is  called  a  thread,  which  facilitates 
the  aggregation  of  a  sequence  of  temporally  and  geographically  contiguous  activities  so  that 
they  may  share  a  set  of  resources  amongst  themselves  without  having  to  allocate  them  each 
individually.  It  is  often  the  case  that  a  series  of  activities  may  require  the  same  resource  or 
collection  of  resources  to  be  used  by  each  constituent  activity,  as  when  a  military  taskforce  is 
configured  and  assigned  to  perform  an  entire  mission  or  some  portion  of  a  mission,  and  is 
also  responsible  for  providing  its  own  equipment.  Threads  effectively  define  a  local  context 
within  which  a  set  of  resources  can  be  shared  by  a  group  of  activities.  During  the  time  when 
resources  are  assigned  to  a  thread,  they  are  available  exclusively  to  the  activities  that  comprise 
the  thread.13  The  basic  thread  structure  is  presented  in  Figure  15. 

The  constraints  on  thread  creation  are  as  follows: 

•  Activities  must  abut  one  another;  the  temporal  sequencing  constraint  (i.e.,  successor,  be¬ 
fore)  between  each  activity  must  have  temporal  bounds  of  [0,0] 

•  The  sequence  of  activities  must  reflect  a  continuous  route  from  one  specific  location  to 
another,  as  specified  by  a  move’s  origin  and  destination  or  an  event’s  place 


An  example  (albeit  simplified)  of  the  use  of  threads  in  a  plan  is  provided  in  the  Section  5.2, 
which  describes  the  Embassy  Rescue  scenario.14 

13A  more  detailed  description  of  how  resources  are  assigned  to  threads  is  presented  in  Section  3. 2. 2. 6 
(Taskforces),  which  introduces  the  concept  of  a  taskforce. 

14Threads  must  currently  be  defined  using  an  additional  data  file  that  accompanies  the  scenario- pi  an.  xml  file, 
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3.2.2  Resources 


Comirem  supports  the  definition  of  both  stationary  and  mobile  renewable  resources.15  Sta¬ 
tionary  resources  (called  either  places  or  components)  reside  at  a  fixed  geographic  location,  while 
mobile  resources  may  move— or  be  moved— from  location  to  location  at  speeds  determined  by 
their  characteristics  and  configuration.  Usage  of  stationary  resources  (e.g.,  bases,  airstrips)  is 
a  function  of  (typically)  their  availability  and  capability  to  accommodate  various  tasks.  That  is, 
stationary  resources  are  often  used  simply  as  placeholders/anchors  within  a  plan  to  determine 
movement  requirements  for  mobile  resources,  and  in  such  cases  are  often  not  actually  allocated 
to  activities  (places  and  components  are  described  further  in  Section  3. 2. 2. 5).  They  can,  how¬ 
ever,  be  required  by  activities  and  allocated  by  the  scheduler.  Mobile  resources,  alternatively, 
are  more  complex.  In  some  cases  (e.g.,  involving  transport  vehicles),  usage  depends  not  only  on 
their  capability  to  support  a  given  task,  but  also  on  such  additional  factors  as  capacity,  speed, 
location  and  (historically)  range.16  In  other  cases  (e.g.,  personnel),  usage  can  occur  at  different 
locations  but  may  require  transport  between  locations.  Resources  can  also  be  grouped  into 
higher-level  aggregate  resources  (e.g.,  a  military  taskforce),  to  perform  activities  as  a  single  entity 
for  some  period  of  time. 

All  resources  in  Comirem  are  unit-capacity  resources:  that  is,  they  can  accommodate  only  a 
single  activity  at  a  time— unless  defined  as  uncapacitated  place  components  (see  Section  3. 2. 2. 5). 
Extension  of  the  Comirem  resource  model  to  support  multi-capacity  resources  has  been  identi¬ 
fied  as  a  logical  future  extension  (see  Section  6). 

3. 2. 2.1  The  Resource  Requirement  Hierarchy 

Comirem  provides  a  base  group  of  common  mobile  resource  types,  such  as  aircraft,  sea- 
craft  and  landcraft,  which  define  generic  vehicle  classes  that  may  be  further  specialized  as 
part  of  a  particular  domain  model.  Additionally,  the  FOOT  resource  type  provides  an  organic 
mobile  resource  (i.e.,  of  type  :organi  c)  that  can  be  used  to  represent  the  movement  of  human 
resources.  Accompanying  these  predefined  resource  types  are  a  set  of  model  types,  such  as 
ROTOR  and  FIXED-WING  for  aircraft,  WHEELED  and  TRACKED  for  landcraft,  and  POWER  and  ROW  for 
seacraft.  Together  with  the  set  of  capabilities,  resource  types  and  resource  instances  defined  for 
a  particular  domain  (i.e.,  a  situation),  model  types  provide  a  fourth  level  in  the  hierarchy  for 
specifying  resource  requirements  for  activities  at  multiple  levels  of  abstraction. 

Figure  16  illustrates  a  subset  of  the  resource-requirement  hierarchy  for  aircraft  in  a  particular 
domain.  The  1  i ght-transport  capability  can  be  achieved  using  the  MH-47  and  MH-60  resources 
classes,  while  the  ai  r-drop  capability  can  be  achieved  using  the  MH-60  and  MC-130H  resource 
classes.  Both  the  MH-47  and  MH-60  resources  are  aircraft  of  model  type  ROTOR,  while  the  MC- 
130H  is  a  FIXED-WING.  Finally,  three  instances  of  MH-60  are  shown  at  the  bottom:  MH-60-001, 
MH-60-002  and  MH-60-003.  As  mentioned  earlier,  activities  can  specify  resource  requirements  at 
any  of  these  four  levels  of  abstraction,  which  delivers  valuable  flexibility  to  the  planner  in  cases 
where  specific  requirements  are  not  appropriate. 

since  Comirem  does  not  yet  provide  an  interactive  means  nor  an  XML  data  file  for  thread  specification.  This  is  a 
temporary  limitation. 

1sAt  the  present  time,  Comirem  does  not  support  consumable  resources  (e.g.,  for  items  such  as  fuel,  ammuni¬ 
tion,  money). 

16For  aircraft,  range  is  becoming  less  of  a  constraint  on  usage,  owing  to  the  increased  use  of  in-flight  refueling. 
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Figure  16:  Subset  of  an  aircraft-specific  resource-requirement  hierarchy 


3. 2. 2. 2  Domain-Specific  Resource  Types 

It  is  not  within  the  purview  of  Comirem  to  provide  support  for  all  conceivable  resource  classes. 
Toward  that  end,  and  akin  to  the  similar  support  for  the  definition  of  domain-specific  activity 
types  described  in  Section  3. 2. 1.1  (Hierarchical  Activity  Networks),  Comirem  does  provide  a 
mechanism  for  users  to  define  new  domain-specific  resource  classes  through  the  extension  of 
existing  Comirem  classes  (such  as  ai  rcraft,  landcraft  and  seacraft). 

Figure  17  illustrates  the  definition  of  both  a  domain-specific  resource  type  and  an  instance 
of  this  new  type.  An  MH-47  is  defined  as  an  aircraft  (a  helicopter  of  model  type  ROTOR)  with  an 
average  air  speed  of  177  mph,  which  in  its  default  configuration  can  accommodate  as  cargo, 
55  PAX  (i.e.,  personnel).  Upon  reading  and  processing  the  situation-types .  xml  file  for  this  do¬ 
main,  Comirem  will  establish  the  MH-47  resource  type  by  generating  and  evaluating  the  appro¬ 
priate  class  definition.  Subsequent  MH-47  instance  definitions  appearing  inside  the  situation- 
instances  .xml  file  will  lead  to  the  creation  of  MH-47  instances. 

From  the  perspective  ofthe  Comirem  scheduler,  the  salient  features  of  a  resource  are:  (1 )  its 
availability  and  (2)  its  influence  on  the  expected  duration  of  a  requiring  activity.  For  mobile 
resources,  the  expected  duration  for  a  move  activity  is  determined  by  the  specified  origin  and 
destination  and  the  average  speed  ofthe  resource,  computed  using  a  Great  Circle  calculation. 
At  the  present  time,  in  all  other  cases  (i.e.,  determining  the  expected  durations  for  stationary 
resource  reservations  and  non-moving  mobile  resource  reservations),  Comirem  must  rely  on  du¬ 
rations  specified  using  duration  constraints  accompanying  activity  definitions.  The  resource  at¬ 
tributes  necessary  for  providing  this  information  to  the  scheduler  are  identified  in  the  following 
section.  Just  as  there  is  no  formal  way  to  specialize  behavior  on  user-defined,  domain-specific 
activity  types,  Comirem  presently  lacks  a  formal  mechanism  for  doing  the  same  with  resource 
types.  This  is  a  logical  future  extension  that  is  discussed  in  Section  6. 
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Defines  the  MH-47 
aircraft  resource  type,  a 
ROTOR  model  type 
capable  of  an  average 
speed  of177mphand 
able  to  carry  55  PAX: 


Defines  an  instance  of  a 
base  type  (i.e.,a  place) 
called  home-station 
with  a  specific  location: 


Defines  an  instance  of  an 
MH-47  aircraft  resource 
type  called  MH-47-001, 
located  initially  at  home- 
station  with  capacity 
available  from  1  January 
2002: 


s/futff/on-types.xml: 

<type> 

<aircraft  name=MMH-47"> 

<model -type>ROTOR</model -type> 
<speed  uni ts=Mmph">177</speed> 
<configurations> 

configuration  name=" :default"> 
cargo  max=M55">PAX</cargo> 
</conf i gu  rati on> 

</conf i gu  rati ons> 

</ai rcraft> 

</type> 


s/'M/on-instances.xml: 

<instance> 

<place  name=,,home-station"> 

<type- ref >base</type- ref> 

<placement> 

<location  lati tude="37 .08"  longi tude="-122 . 07"></location> 
</placement> 

</pl ace> 

</i nstance> 

<i nstance> 

cresource  name=,,MH-47-001"> 

<type-  ref>Af//-47</type-  ref> 

<pl  acement>home-stationx/p~\  acement> 

<capaci ty-1 i st> 

<capaci ty-i nterval> 

<start-ti me>20020101T000000</start-ti me> 

<end- ti me> : i nf i ni ty</end-ti me> 

<uni ts>l</uni ts> 

</capaci ty-i nterval> 

</capacity-l i st> 

</resource> 

</i nstance> 


Figure  17:  Annotated  XML  specifications  of  resources 


3. 2. 2. 3  Resource  Attributes 

The  attributes  for  resources,  both  stationary  and  mobile,  are  described  in  Tables  4  and  5,  and 
follow  the  XML  grammars  described  in  Section  A. 3.  As  with  the  activity  instances  discussed  in 
Section  3.2.1 .2  (Activity  Attributes),  note  that  values  for  these  attributes  can  be  provided  either 
at  the  class  level,  as  part  of  the  definition  of  a  specialized  resource  type,  or  at  the  instance  level, 
as  part  of  the  definition  of  a  specific  resource  instance. 
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Table  4:  Resource  type  attributes 


•  Name 

[required] 

The  name  of  the  resource  type 

•  Description 

[optional] 

A  description  of  the  resource 

•  Model-type 

[optional] 

The  name  of  a  predefined  model  type  (e.g., 

ROTOR,  FIXED-WING),  for  classifying 

the  resource 

•  Configurations 

[optional] 

A  collection  of  configurations  that  describe  the  capabilities  of  a  resource  depending 
on  how  it  is  physically  configured  a 

Resource  configurations  are  specified  in  terms  of  the  aforementioned  predefined 
cargo  types  (e.g.,  PAX,  MUNITIONS,  FUEL).  The  default  configuration  permits  un¬ 
limited  cargo  capacity  on  a  resource  (i.e.,  no  siblings  are  required  when  using  it). 

•  Capabilities  [optional] 

A  list  of  capabilities  that  can  be  delivered  by  this  resource 

Capabilities  appearing  in  this  list  need  not  be  predefined.  If  referenced  forthe  first 
time  in  this  list,  a  new  capability  object  will  be  created  on  the  fly  and  linked  to  the 
resource. 

•  Speed  [required] 

For  a  mobile  resource,  its  average  traveling  speed 

•  Range  [ ignored ] 

For  a  mobile  resource,  its  maximum  travel  range  b 

"Configurations  in  Comirem  are  currently  treated  as  though  they  can  be  changed  instantaneously,  as 
if  they  are  achievable  by  means  of  zero-duration  setup  actions.  Note,  however,  that  the  modifications 
necessary  to  support  true  situation-dependent  setups  are  relatively  minor. 
bAt  the  present  time,  Comirem  does  not  enforce  range  constraints. 
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Table  5:  Resource  instance  attributes 


•  Name 


[required] 


The  name  ofthe  resource 


•  Type-Ref 


[required] 


The  type  ofthe  resource:  either  mobi  1  e,  pi  ace,  component,  ai  rcraft,  1  andcraft 
or  seacraft 


•  Placement 


[required] 


The  placement  of  a  resource 

For  mobile  resources  this  is  an  initial  location.0 

Places  can  only  be  placed  at  latitude/longitude  locations.  Mobile  resources  and 
components  can  be  placed  at  either  a  latitude/longitude  location  or  another  place 
instance. 

•  Components  [optional] 

For  place  resources,  the  collection  of  capacitated  component  resources  residing 

with  them  (e.g.,  runways  at  an  airport) 

•  Uncapacitated-components  [optional] 

For  place  resources,  the  collection  of  unlimited-capacity  component  resources  re¬ 
siding  with  them,  specified  in  terms  of  capability,  model  type  or  resource  class 

•  Capacity-list  [optional] 

A  sequence  of  possibly  non-contiguous  capacity  intervals,  indicating  at  the  outset, 
the  time  windows  during  which  the  resource  is  available  for  allocation  (i.e.,  akin 
to  business  hours) 

Note  that  Comirem  currently  only  supports  unitary  capacity  intervals.  The  default 
capacity  window  extends  for  the  entire  scheduling  horizon. 

aAn  altitude  can  also  be  provided,  although  it  is  currently  ignored.  Travel-distance  calculations  are 
made  under  the  assumption  that  all  locations  are  at  the  same  altitude  (e.g.,  sea  level). 
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3. 2. 2.4  Flexible  Timelines 


As  has  been  mentioned  earlier,  Comirem  implements  a  flexible  time-bounds  scheduling  approach 
that  avoids  assigning  specific  fixed  time  intervals  to  the  activities  in  a  plan  when  allocating  re¬ 
sources.  Instead,  resource  assignments  become  floating  reservations  that  can  move  forward 
and  backward  (i.e.,  downstream  and  upstream)  in  time  according  to  their  latest  finish  times 
and  earliest  start  times,  respectively.  As  activities  are  scheduled  on  a  resource,  existing  reserva¬ 
tions  are  pushed  aside  to  make  room  for  the  insertion  of  new  reservations.  It  is  only  when  such 
shifting  will  not  open  up  enough  room  for  a  new  reservation  that  the  scheduler  gives  up  and 
considers  another  resource  candidate  instead. 


Activities  requiring  mobile  resource  R1 


Activity  A1  [wrapper] 


All 

Al2  [nexus] 

A13 

A12i 

AI22 

A12b 

•  • 

A  B 


v  A 

^  J 

A3 

L 

•4+# 

F  G 


Activity  A2  [wrapper] 

A2i 

A22  [nexus] 

A22i 

A222 

kill 

o- 

7 


mobile  resource  movement 
E  w/free  resource-origin  variable  F 


Resource  R1  timeline  &  locations  over  time 


finish-time  ^  start-time 
range:  A1  y  range:  A2 


Any  resource  assignment  to  this  interval  must  ensure  that  R1  can  | 
get  to  location  E  from  the  new  activity's  final  location  by  LST(A22). 


finish-time 

range:  A2  finish-time 
start-time  range:  A3 
range:  A3 


A3 


Figure  18:  Insertion  of  activities  onto  a  mobile  resource  timeline 


In  Figure  18  (top),  note  that  three  activities:  A1,  A2  and  A3,  all  require  the  use  of  re¬ 
source  R1.  Note  also  that  activity  A1  requires  R1  to  be  sourced  from  location  A  and  returned 
to  location  D,  while  A2  has  its  resource  origin  declared  as  a  free  variable  and  leaves  R1  at  its 
destination  location  F.  Activity  A3  simply  requires  R1  to  start  at  location  F  and  finish  up  at  G. 
Activities  A2  and  A3  can  easily  be  scheduled  in  sequence  on  R1  because  of  the  shared  resource 
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location  F  and  the  flexibility  in  the  finish-time  range  for  A2  and  the  start-time  range  for  A3  (i.e., 
despite  the  overlap,  there  is  still  room  for  both  to  use  R1 ).  Similarly,  activities  A1  and  A2  have 
no  temporal  overlap  at  all,  even  if  A2  has  to  secure  R1  from  location  D. 

Once  activities  A1 ,  A2  and  A3  have  been  assigned  to  resource  R1  (bottom  of  Figure  18),  the 
interval  of  available  capacity  between  A1  and  A2  takes  on  an  additional  (implicit)  constraint, 
which  is  that  any  reservation  within  that  interval  must  leave  activity  A2  with  enough  time  for  it 
to  source  R1  from  the  new  activity’s  final  location  to  location  E  by  the  latest  start  time  of  A22- 
Otherwise,  until  either  ofthe  reservations  for  A1  orA2  is  modified  or  retracted,  the  new  activity 
cannot  be  inserted  into  that  interval. 

3. 2. 2. 5  Place  Components 

A  stationary  place  resource  in  Comirem  can  serve  as  its  own  resource  and  also  provide  a  col¬ 
lection  of  component  resources  that  reside  at  its  location.  A  typical  example  is  an  airport, 
which  can  provide  runways  and  aircraft-parking  areas  that  can  be  reserved  individually.  Such 
components  can  also  be  uncapacitated,  in  which  case  they  provide  unlimited  capacity— at  a  par¬ 
ticular  location— specified  in  terms  of  capability,  resource  type  or  model  type.  Components 
are  allocated  to  events  that  require  their  capacity  and  reference  their  corresponding  place  (i.e., 
component  capacity  at  place  P  can  only  be  allocated  to  events  with  a  <pl  ace>P</pl  ace>  tag). 

Figure  19  presents  a  collection  ofXML  forms  that  demonstrate:  (1 )  the  definition  of  a  place- 
component  resource  type  called  worki  ng-MOG,  (2)  a  capacitated  instance  ofworki  ng-MOG  called 
embassy-yard  located  at  an  embassy  place  instance,  (3)  the  embassy  place  instance  showing 
embassy-yard  as  a  component,  (4)  a  place  instance  called  home-station  providing  unlim¬ 
ited  (i.e.,  uncapacitated)  worki  ng-MOG  capacity,  and  finally,  (5)  an  activity  type  called  load- 
step  that  requires  worki  ng-MOG  capacity.  Simply  put,  this  example  describes  two  sources  of 
worki  ng-MOG  capacity  that  may  be  used  by  instances  ofthe  load-step  activity  type.  Ifworki  ng- 
MOG  is  required  from  the  embassy  location,  it  must  come  from  the  embassy-yard  place  compo¬ 
nent  and  be  allocated  by  the  scheduler  depending  on  its  availability.  If,  on  the  other  hand, 
worki  ng-MOG  is  required  from  the  home-stati  on  location,  it  is  automatically  available  without 
any  interaction  with  the  scheduler,  because  its  capacity  is  unlimited. 

Places  can  be  defined  as  part  of  either  a  situation  (i.e.,  within  the  situation- i  nstances .  xml 
data  file)  or  a  scenario  (i.e.,  within  the  scenario- pi  an.  xml  data  file).  The  distinction  is  subtle 
but  relevant.  The  determining  factor  is  whether  the  place  is  conceptually  a  part  ofthe  bed- 
down  information  that  comprises  a  situation  or  is  a  location  specific  to  a  particular  scenario. 
For  example,  a  default  bed-down  situation  may  define  a  collection  of  military  aircraft  wings 
deployed  among  a  numberof  bases  to  be  used  by  a  range  of  scenarios.  In  this  case,  the  scenario 
must  conform  to  the  constraints  dictated  by  the  geographic  placement  ofthe  resources  defined 
in  the  situation.  In  the  latter  case,  places  are  locations  that  are  specific  to  the  scenario,  in 
that  they  define  points  in  the  plan  where  actions  are  expected  to  occur,  and  can  be  legitimately 
referenced  within  the  plan.  In  most  cases,  it  is  to  be  expected  that  some  places  will  be  defined 
as  part  ofthe  situation  while  others  are  specific  to,  and  defined  as  part  of,  a  particular  scenario. 
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© 

Defines  the  working-MOG 
place-component  resource 
type, giving  it  a  maximum 
serving  capacity  of  a  single 
AIRCRAFT: 

<type> 

<component  name="working-MOG"> 
conf  i gu  rati ons> 

configuration  name="  : defaul t"> 
cargo  max="lM>AIRCRAFT</cargo> 

</configuration> 

</confi gurati ons> 

</component> 

</type> 

© 

Defines  an  instance  of  a 
working-MOG  place- 
component  called  embassy- 
yard  to  be  located  at  an 
embassy  place  instance 
(defined  below),  with 
unitary  capacity  and 
unlimited  availability: 

<i nstance> 

component  name=,,embassy-yard"> 

<type- r ef >working-MOG</ type- ref> 

<pl  acement>e/nbassy</pl  acement> 

<capaci ty-1 i st> 

<capacity-i nterval 

<start-ti me>20010101T000000</start-ti me> 

<end-ti me> : i nf i ni ty</end-ti me> 

<uni ts>l</uni ts> 

</capaci ty-i nterval > 

</capacity-li st> 

</component> 

</i nstance> 

© 

Defines  the  embassy 
place  instance  listing  the 
embassy-yard  as  a 
(capacitated)  place- 
component: 

<i nstance> 

<place  name=,,embassy"> 

<type- ref>base</type- ref> 

<placement> 

<location  1 ati tude="38 . 17"  longi tude="-122 . 3"></location> 
</placement> 

component  s>e/wbassy-yarc/</components> 

</place> 

</i nstance> 

© 

Defines  the  home-station 
place  instance  providing 
uncapacitated  working- 
MOG  capacity: 

<i nstance> 

<place  name=,,home-station"> 

<type- ref>base</type- ref> 

<pl acement> 

<location  1 ati tude="37 . 08"  1 ongi tude="-122 . 07"></l ocati on> 
</placement> 

<uncapaci tated-components> 

<resou  rce-cl ass>worki ng-MOG</ resou rce-cl ass> 

</uncapaci tated-components> 

</place> 

</i nstance> 

© 

Defines  the  load-step 
(event)  activity  type 
requiring  working-MOG 
resource  capacity: 

<type> 

<event  name="load-step"> 

<requi rements> 

<requi rement> 

<resou rce-cl  ass>worki ng-MOG</ resou rce-cl ass> 

</requi rement> 

</requi rements> 

</event> 

</type> 

Figure  19:  Annotated  XML  specifications  of  (un)capacitated  places  and  place  components 
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3. 2. 2. 6  Taskforces 


Somewhat  analogously  to  the  way  in  which  multiple  activities  can  be  grouped  together  into 
threads  (as  described  in  Section  3. 2. 1.5,  Threads),  Comirem  also  supports  the  aggregation 
of  resources  into  high-level  taskforces.  A  taskforce  is  a  collection  of  resources  that  have  been 
grouped  together  for  a  specific  period  of  time,  during  which  they  can  be  allocated  collectively— 
to  threads— as  a  single  resource  object.  Taskforce  resources  are  required  to  be  either  mobile 
resources  or  movable  (i.e.,  non-place-component)  stationary  resources  that  can  be  transported, 
since  they  must  be  able  to  move,  or  be  moved,  from  location  to  location  as  required  by  a  thread. 
Certain  predefined  mobile  resource  classes  (e.g.,  those  that  are  typically  sourced  from  base  loca¬ 
tions)  may  require  that  additional  positioning  and  depositioning  legs  be  instantiated  to  deliver 
them  to  the  starting  location  of  a  thread  and  back  from  the  ending  location.  Mobile  resources 
that  are  not  positionable  are  required  to  already  be  located  at  the  start  location  for  the  thread 
to  which  the  taskforce  will  be  assigned. 

The  resource-aggregation  capability  provides  two  key  benefits: 

1 .  Scheduling  efficiency  through  aggregation: 

The  definition  of  a  taskforce  facilitates  the  allocation  of  a  single  collection  of  resources  to 
perform  a  sequence  of  activities  comprising  a  thread,  so  that  Comirem  need  not  allocate 
each  individual  resource  to  the  thread. 

2 .  Explicit  and  detailed  tracking  of  constituent  resources: 

Constituent  resources  within  a  taskforce  can  be  easily  located  over  time  as  threads  are 
scheduled  and  executed.  Since  taskforces  are  treated  as  single  objects,  their  specific  make¬ 
up  can  be  ignored  at  the  scheduling  level.  But  their  make-up  is  recorded  explicitly,  and  can 
therefore  be  used  to  rapidly  determine  both  where  a  specific  constituent  resource  is  located,  and 
which  constituent  resources  are  present  at  a  location,  at  any  point  in  time.  For  real-time  battle 
management,  these  are  important  queries  to  be  capable  of  answering. 

The  duration  of  a  taskforce  depends  on  the  thread  to  which  it  is  allocated.17  Until  it  is  allo¬ 
cated  to  a  thread,  a  taskforce’s  duration  is  unbounded.  Throughoutthe  duration  of  a  taskforce, 
its  constituent  resources  may  not  be  allocated  to  any  other  activity  or  taskforce,  in  which  case,  if 
a  taskforce  has  not  yet  been  allocated  to  a  thread,  its  constituents  can  only  be  allocated  to  that 
taskforce.  Once  a  taskforce’s  bounds  have  been  set  by  its  allocation  to  a  thread,  its  constituent 
resources  are  free  to  be  allocated  to  other  activities  and  taskforces  whose  temporal  bounds  do 
not  overlap  those  of  the  taskforce  to  which  they  are  already  assigned. 

Constituent  resources  are  available  for  use  by  any  and  all  activities  within  the  thread  to  which 
they  are  allocated.  Since  the  constituents  are  required  to  be  mobile  in  nature,  they  are  assumed 
to  be  able  to  travel  from  location  to  location  as  dictated  by  the  thread’s  activity  sequence.  And 
since  a  thread’s  activity  sequence  is  precluded  from  allowing  overlap,  there  is  no  possibility  of 
two  activities  within  a  thread  attempting  to  use  the  same  resource  at  the  same  time. 

Figure  20  illustrates  the  relationships  between  a  taskforce,  its  constituent  resources,  and  a 
thread.  Like  a  typical  Comirem  resource,  each  taskforce  maintains  its  own  timeline  upon  which 

17Currently,  Comirem  restricts  taskforces  from  being  assigned  to  more  than  a  single  thread.  One  way  around  this 
restriction,  however,  is  to  define  multiple  taskforces,  assign  each  to  a  desired  thread,  and  then  allocate  the  same 
set  of  constituent  resources  to  each  taskforce. 


36 


its  thread  assignment  is  placed,  like  a  regular  resource  reservation.  When  a  resource  joins  a 
taskforce,  a  taskforce-participation-event  is  placed  on  its  timeline,  with  its  duration  and  flexibil¬ 
ity  dictated  by  the  duration  and  flexibility  of  a  thread  possibly  assigned  to  the  taskforce  (via 
multiple  same-start  and  same-finish  temporal  constraints),  and  whether  or  not  derivative 
(de)positioning  legs  are  required.  If  no  thread  has  been  assigned  to  the  taskforce,  the  dura¬ 
tion  of  the  taskforce-participation-event  is  unbounded,  and  there  is  no  flexibility  (i.e.,  the  taskforce- 
participation-event  reservation  takes  up  the  resource’s  entire  timeline). 

The  overall  feasibility  of  a  taskforce  assignment  (to  a  thread)  is  dependent  on  the  timelines 
of  its  constituent  resources  and  the  requirements  of  the  thread  to  which  it  may  be  assigned. 
Additionally,  the  existing  timelines  of  the  constituent  resources  assigned  to  a  taskforce  constrain 
the  extent  of  both  the  taskforce  and  the  thread  to  which  it  may  be  assigned. 


Figure  20:  Taskforce  structure  and  relationships  to  thread  and  resource  timelines 


It  should  be  noted  here  that  currently  there  are  some  limitations  on  the  means  by  which 
taskforces  are  defined  in  Comirem.  Specifically,  taskforces  must  be  assembled  by  hand  using 
the  Resource  &  Taskforce  Manager  in  the  Comirem  GUI  (described  in  Section  B.4.2).18 

An  example  ofthe  use  ofthreads  in  Comirem  can  be  found  in  the  description  ofthe  Embassy- 
Rescue  domain  presented  in  Section  5.2,  in  which  three  taskforces  are  defined  to  undertake 

^Augmentation  ofthe  Comirem  data  file  XML  formats  (described  in  Appendix  A)  is  anticipated  to  allow  task- 
forces  to  be  specified  declaratively  as  part  of  an  input  situation. 
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three  different  threads  comprising  a  mission  to  rescue  personnel  from  a  United  States  embassy 
on  foreign  soil. 

3.2.3  Constraints 

In  addition  to  the  previously  mentioned  constraints  on  activities  and  resources,  Comirem  pro¬ 
vides  the  ability  to  synchronize  activities  (and  by  extension,  threads)  using  three  different  kinds 
of  constraints.  A  set  of  temporal  sequencing  constraints  governs  the  relationships  between  ac¬ 
tivities,  a  reference-hour  constraint  facilitates  the  linking  of  activities  to  movable  time  points, 
and  an  anchoring  constraint  facilitates  the  placement  of  lower  and  upper  bounds  on  the  start 
and  finish  times  of  activities.  These  constraint  types  are  described  in  the  following  subsections. 

3. 2. 3.1  Temporal  Sequencing  Constraints 

To  support  the  relative  sequencing  of  activities,  Comirem  implements  a  set  of  canonical  binary 
temporal  relations,  such  as  before,  same-start  and  same-finish,  and  overlaps  and  contains.  These 
relations  enforce  sequencing  rules  while  attemptingto  preserve  flexibility  within  the  time  bounds 
of  constrained  activities. 

Figure  21  illustrates  the  before  constraint  (also  called  successor),  which  can  also  be  used  to 
implement  an  after  relation,  by  reversing  the  order  of  the  activities.  The  before  constraint,  cou¬ 
pled  with  a  [lb,ub]  temporal  range,  forces  one  activity  (i.e.,  A2)  to  start  within  a  time  window 
offset— shown  in  red— from  the  end  time  of  another  activity  (i.e.,  A-| ).  Note  that  if  the  lower 
bound  is  negative,  then  overlap  between  the  activities  is  allowed. 


A1  before  A 

2  [lb,ub] 

ET(A,)  ST(A2) 

v  1 

A1 

A2 

[ 

I 

■ 

l 

ET(A,)+lb 

ST(A2) 

ET(A,)+ub 

before(  A-| ,  A2  lb,  ub  ) 

[ET(A-| )  +  lb]  <  ST(A2)  <  [ET(A-, )  +  ub] 
default  values:  [lb,ub] :  [0,oo] 


Figure  21 :  Successor  (also  before  and  after )  constraint 
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In  Figure  22,  the  same-start  and  same-finish  constraints  are  illustrated.  In  the  left  half  of  the 
figure,  the  same-start  relation  forces  one  activity  (i.e.,  A2)  to  start  within  a  time  window  offset— 
again  shown  in  red— from  the  start  time  of  another  activity  (i.e.,  A-| ).  In  the  right  half  of  the 
figure,  the  same-finish  relation  forces  one  activity  (i.e.,  A2)  to  finish  within  a  time  window  offset 
from  the  end  time  of  another  activity  (i.e.,  A-j ).  Note  that  a  negative  lower  bound  on  the  same- 
start  constraint  permits  A2  to  actually  start  before  A-| ,  and  that  a  negative  upper  bound  on  the 
same-finish  constraint  permits  A2  to  actually  finish  after  A-| . 


A1  same-start  A2  [lb,ub] 

ST(A, ) 


A1  same-finish  A2  [lb,ub] 

m 

ET(A2) 

1 

A, 

a2 

L 

L 

ET(A,)+lb  ET(A2)  ET(A,)+ub 

same-start(  A-| ,  A2,  lb,  ub  ) 

same-finish(  A-| ,  A2  lb,  ub  ) 

[ST(A-| )  +  lb]  <  ST(A2)  <  [ST(A-| )  +  ub] 

default  values:  [lb,ub]:  [0,oo] 

[ET(A-| )  +  lb]  <  ET(A2)  <  [ET(A-| )  +  ub] 

default  values:  [lb,ub]:  [— 00, 0] 

Figure  22:  Same-start  and  same-finish  constraints 
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Figure  23  illustrates  the  overlaps  and  contains  constraints.  In  the  left  half  of  the  figure,  the 
overlaps  relation  forces  one  activity  (i.e.,  A2),  to  start  within  a  time  window  offset  from  the  end 
time  of  another  activity  (i.e.,  A-j ).  In  the  right  half  of  the  figure,  the  contains  relation  forces  one 
activity  (i.e.,  A2),  to  both  (1 )  start  within  a  time  window  offset  from  the  start  time,  and  (2)  end 
within  a  time  window  offset  from  the  end  time,  of  another  activity  (i.e.,  A-| ). 
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(V1  )+ub1  ET(A|  )+ub2 

overlaps(  A-| ,  A2,  lb,  ub  ) 

contains(  A-| ,  A2  lb-| ,  ub-| ,  lb2,  ub2  ) 

[ET(A-| )  +  lb]  <  ST(A2)  <  [ET(A-| )  +  ub] 

default  values:  [lb,ub] :  [— 00, 0] 

[ST(A-| )  +  lb-,  ]  <  ST(A2)  <  [ST(A-| )  +  ub!  ] 

A  [ET(A-, )  +  lb2]  <  ET(A2)  <  [ET(A-| )  +  ub2] 

default  values:  [lb-|,ub-|]:  [0,oo] 

[lb2,ub2]:  [-oo,0] 

Figure  23:  Overlaps  and  contains  constraints 

In  all  ofthese  cases,  the  default  [lb,ub]  values  are  set  to  enforce  a  strict  interpretation  ofthe 
constraint  relation.  As  has  been  pointed  out,  however,  these  relations  can  be  relaxed  through 
the  specification  of  different  lower  and  upper  bounds. 
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The  basic  attributes  of  the  five  temporal  sequencing  constraint  types  are  described  in  Ta¬ 
ble  6.  The  XML  format  for  specifying  instances  of  these  constraints  as  part  of  a  scenario-^  an .  xml 
data  file  is  presented  in  Section  A.1 .4.1 . 


Table  6:  Temporal  sequencing  constraint  attributes 


•  Type-Ref  [required] 

Indicates  the  type  of  constraint:  must  be  one  of  successor,  before,  same-start, 
same-fi ni sh,  overl aps  or  contai ns. 

•  From  |  From -Type  [required] 

Identifies  the  set  of  activities  from  which  the  constraint  originates  (corresponding 
to  the  A-| ’s  in  Figures  21 ,  22  and  23) 

Notice  that  activities  can  be  identified  by  name  (using  the  From  attribute),  or  by 
type  (using  From-Type).  The  latter  is  used  primarily  for  specifying  sequencing  rela¬ 
tions  among  child  activities,  in  which  case  the  types  of  the  children  must  be  unique. 

•  To  |  To-Type  [required] 

Identifies  the  set  of  activities  to  which  the  constraint  is  directed  (corresponding  to 
the  A2’s  in  Figures  21 , 22  and  23) 

To-Type  is  used  analogously  to  From-Type. 

•  LB  [optional] 

Provides  the  lower  bound  on  the  time  window  for  a  constraint 

•  UB  [optional] 

Provides  the  upper  bound  on  the  time  window  for  a  constraint 


3.2. 3. 2  Reference  Hour  Constraints 

To  achieve  a  possibly  tighter  degree  of  synchronization  of  activities,  Comirem  provides  reference 
hour  (or  ref-hour)  constraints  for  linking  sets  of  activities  to  a  relative  date,  which  can  be  assigned 
to  a  particular  point  in  time  and  shifted  as  necessary.  An  activity  can  be  linked  to  a  ref-hour  by 
either  its  start  or  finish  time,  or  both.  These  links  define  what  we  call  the  preferred  start  and 
finish  times  for  the  activity. 

One  benefit  of  the  reference  hour  constraint  type  is  the  ability  to  define  collections  of  activ¬ 
ities  (i.e.,  plan  fragments)  whose  temporal  bounds  can  be  manipulated  collectively  by  shifting 
a  single  reference  point  in  time.  This  capability  is  ideal  for  defining  the  N  hour  and  FI  hour  syn¬ 
chronization  points  typically  used  in  military  plans.  During  the  planning/scheduling  process,  if 
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H  hour  is  shifted  by  a  day,  then  the  preferred  start/finish  times  of  all  activities  linked  to  H  hour 
will  similarly  be  shifted  by  the  same  amount.19 

Another  benefit  of  the  ref-hour  constraint  derives  from  the  fact  that  each  reference  hour 
maintains  its  own  flexible  time  window  (defined  by  upper  and  lower-bound  offsets  from  the  ref- 
hour’s  time  point),  which  establishes  a  “level  of  precision”  with  respect  to  the  synchronization 
of  activities  (the  default  is  ±3  minutes).  If  the  preferred  start/finish  times  of  linked  activities 
occur  within  this  level  of  precision  (or  tolerance)  as  execution  unfolds,  a  plan  is  considered  to  be 
executing  as  planned. 

The  relationship  between  a  reference  hour,  calendar  zero,  and  a  linked  activity  is  illustrated 
in  Figure  24. 


preferred  preferred 

start  time  finish  time 


The  ST  and  FT  offsets 
from  the  REF-HOUR 
determine  the  pre¬ 
ferred  start  and  finish 
times  for  the  activity. 


The  REF-HOUR  preci¬ 
sion  level  and  the  ST 
and  FT  offsets  dictate 
the  activity's  start  and 
finish-time  ranges. 


The  LB  and  UB  values 
determine  the  preci¬ 
sion  level  of  the  REF- 
HOUR. 


CZ  offset  fixes  the 
REF-HOUR  along 
the  timeline. 


. 

timeline 


Figure  24:  Reference  hour  constraint  representation 


19Note  that  the  flexibility  of  a  reference  hour  is  collectively  constrained  by  its  linked  activities,  so  that  it  may  only 
be  shifted  as  long  as  sufficient  flexibilityfor  those  activities  exists  in  the  schedule. 
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3.2. 3. 3  Anchoring  Constraints 

Anchoring  constraints  introduce  lower  and  upper  bounds  on  the  start  and  finish  times  of  ac¬ 
tivities,  for  defining  not-earlier-than  (i.e.,  NET  or  EST/EFT)  and  not-later-than  (NLT  or  LST/LFT) 
temporal  relations.  Release  dates  and  due  dates  are  typical  anchors:  a  release  date  imposes  an 
EST  constraint  on  the  initial  activities  in  a  plan,  while  a  due  date  imposes  an  LFT  constraint  on 
the  final  activities  in  a  plan.  Anchoring  constraints  are  specified  for  activity  instances  using  the 
EST,  LST,  EFT  and  LFT  attributes  described  in  Table  2.  The  anchoring  constraint  representation 
is  illustrated  in  Figure  25. 


EST  constraint 
e.g.,  a  Release  Date 


start 

time  range 


finish 
time  range 


a 


ACTIVITY 


a- 


LFT  constraint 
e.g.,  a  Due  Date 


. 

timeline 


Figure  25:  Anchoring  constraint  representation 


3.2.4  Capabilities 

As  mentioned  in  Section  3.2  (Conceptual  Model),  Comirem  supports  both  the  direct  mapping 
of  activities  to  their  required  resources  and  the  indirect  mapping  via  capabilities,  which  collec¬ 
tively  define  a  high-level  categorization  of  resource  types  according  to  the  kinds  of  services  they 
provide  (e.g.,  heavy  and  light  transport,  airlift,  close  air  support). 

Capabilities  are  defined  in  as/'twdt/ofl-capabilities.xml  input  data  file  using  the  attributes 
and  tags  described  in  Table  7.  Figure  26  provides  an  example  of  some  standard  SOF-related 
capabilities,  which  follow  the  XML  grammar  described  in  Section  A. 4. 
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Table  7:  Capability  attributes 


•  Name  [required] 

The  name  of  the  capability,  for  reference  in  the  resource-requirements  of  activities 

and  the  configurations  of  resources 

•  Capable-Types  [required] 

The  set  of  resource-classes  that  can  deliver  the  capability 

The  mapping  between  capabilities  and  resources  need  only  be  specified  in  one 
direction  (i.e.,  from  capability  to  resource  using  this  tag,  or  from  resource  to  ca¬ 
pability  using  the  capabilities  or  configurations  tags;  Comirem  will  fill  in  the 
missing  inverse  links. 

•  lype-Ref  [required] 

Characterizes  the  capability  as  applying  to  either  a  move  or  event  activity 

This  tag  is  primarily  for  helping  to  organize  and  present  information  to  the  user 
in  a  meaningful  fashion  -  i.e.,  so  that  capabilities  related  to  movement  are  only 
offered  as  options  for  move  activities,  and  capabilities  related  to  stationary  actions 
are  only  offered  as  options  for  event  activities. 


<capabi 1 i ty  name="heavy-transport"> 

<capabl e-types>MC-130H  C-141</capabl e-types> 
<type- ref>move</type- ref> 

</capability> 

<capabi 1 i ty  name="l ight-transport"> 

<capabl e-types>MH-60  MH-47</capabl e-types> 
<type- ref>move</type- ref> 

</capability> 

capability  name="air-drop"> 

<capabl e-types>MH-60  MC-130H</capabl e-types> 
<type- ref>move</type- ref> 

</capability> 


Figure  26:  XML  specifications  for  capabilities 
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3.2.5  Plans 

A  plan  in  Comirem  is  a  collection  of  activities  defining  a  single,  coordinated  mission.  The  sce¬ 
nario-plan  ,xm~\  file  in  which  a  plan  is  defined  contains  the  activity  and  constraint  instances  that 
describe  the  actions  needing  to  be  taken  and  the  order  in  which  they  must  be  performed.  Once 
loaded  into  an  existing  situation,  the  feasibility  of  a  plan/scenario  can  be  ascertained  through  a 
process  of  either  automatic  or  manual  interactive  scheduling. 

The  last  remaining  data  fragment  used  in  specifying  a  plan  is  the  plan  configuration,  which 
provides  the  necessary  temporal  information  for  interpreting  the  scenario-plan  .xml  data  file. 
The  various  attributes  for  the  configuration  tag  are  described  in  Table  8  and  follow  the  XML 
grammar  described  in  Section  A. 5. 


Table  8:  Plan-configuration  attributes 


[optional] 


[optional] 


•  Display-Name 

An  appropriate  display  name  for  the  plan  (i.e.,  for  use  in  the  GUI) 

•  Calendar-Zero 
The  base  time  value  for  all  times  specified  within  a  plan 

This  value  is  relevant  whenever  the  times  in  a  plan  are  specified  as  integer  values, 
in  which  case  each  such  value  represents  an  absolute  time  (i.e.,  not  an  offset).  (It 
is  preferable  to  specify  times  consistently  within  a  plan,  i.e.,  either  as  integer  values 
or  explicit  dates/times.)  The  default  is  0. 

•  Calendar-Zero-Date  [optional] 

A  calendar  date/time  for  initializing  Comirem’s  calendar-zero  v alue 

Integer  time  values  within  a  plan  are  mapped  into  Comirem’s  internal  temporal 
representation,  which  maintains  its  own  calendar-zero. 

The  default  is  the  value  of  Comirem’s  (time-today)  function. 

•  Ref-Hours  [optional] 

Specifications  of  all  ref-hours  for  a  plan 

Ref-hour  specifications  include  the  name  of  the  ref-hour,  its  time  point,  and  its 
delta  value,  which  is  used  to  provide  a  window  of  temporal  flexibility  around  the 
time  point. 

•  Plan-Horizon  [optional] 

The  horizon  for  the  plan  The  default  is  24  hours. 

•  Time-Granularity  [optional] 

The  temporal  granularity  of  the  plan  The  default  is  ‘seconds.’ 
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3.3  Scheduler 


Comirem  takes  a  flexible-times  approach  to  allocating  resources  to  activities  over  time.  Activities 
in  the  plan  are  allowed  to  float  within  the  time  bounds  that  are  permitted  by  current  problem 
constraints,  and  the  feasibility  ofvarious  resource  assignments  is  ensured  by  sequencing  any  pair 
of  activities  that  are  assigned  the  same  resource.  This  approach  can  be  contrasted  with  most 
current  scheduling  tools,  which  ensure  resource  feasibility  by  assigning  fixed  start  and  end  times 
when  allocating  resources  to  activities.  Fixed-time  scheduling  can  simplify  the  enforcement  of 
various  resource  usage  constraints  but  it  also  generally  implies  considerable  overcommitment. 
Under  a  flexible-times  scheduling  approach,  alternatively,  greater  flexibility  is  retained.  At  both 
plan  development  and  plan  execution  stages,  this  minimizes  the  need  for  change. 

3.3.1  Managing  Temporal  Constraints 

Within  this  flexible-times  framework,  temporal  constraint  propagation  and  consistency  enforce¬ 
ment  is  achieved  by  encoding  various  elements  ofthe  plan  as  a  SimpleTemporal  Problem  (STP) 
constraint  network  [Dechter  etui.,  1991],  and  applying  an  incremental  STP  constraint  network 
solver.  Briefly,  temporal  constraints  are  represented  in  an  underlying  graph  C(N,  E },  where 
nodes  in  N  represent  time  points,  and  edges  in  E  are  distances  (labeled  as  [lower  bound,  up¬ 
per  bound]  pairs)  between  the  time  points  in  N.  A  special  time  point,  called  “calendar  zero,” 
grounds  the  network  and  has  the  value  0.  The  network  maintains  lower  and  upper  bounds 
on  the  time  points  by  propagating  the  bounds  on  the  distances  ofthe  edges.  Activities,  ref- 
hours,  anchors  and  temporal  sequencing  constraints  are  uniformly  represented  as  temporal 
constraints  (i.e.,  edges)  between  relevant  start  and  finish  time  points,  as  depicted  in  Figure  27. 
Planning/scheduling  decisions  generally  correspond  to  the  introduction  of  new  constraints  into 
the  network  (e.g.,  sequencing  two  activities  that  have  been  assigned  the  same  resource)  or  the 
adjustment  of  existing  constraints  (e.g.,  refining  the  duration  of  an  activity,  moving  an  anchor). 
In  either  case,  constraint  propagation  updates  the  bounds  of  affected  nodes  and  checks  for 
cycles  in  the  resulting  network.  The  lack  of  any  such  cycle  ensures  continued  temporal  feasibil¬ 
ity  ofthe  plan.  Otherwise  a  conflict  has  been  detected,  and  backtracking  (or  some  amount  of 
constraint  relaxation)  is  necessary. 

3.3.2  Managing  Resource  Constraints 

As  implied  above,  basic  resource  feasibility  is  maintained  by  enforcing  a  disjunctive  constraint 
on  the  execution  of  any  two  activities  utilizing  the  same  resource.  If  two  such  activities  would 
otherwise  have  potentially  overlapping  execution  windows,  preservation  of  feasibility  requires 
that  an  explicit  sequencing  constraint  be  introduced.  Note  that  for  an  activity  requiring  several 
resources,  this  can  imply  several  distinct  links. 

Comirem  provides  a  number  of  more  specialized  resource  constraint  management  tech¬ 
niques,  aimed  at  satisfaction  of  additional  resource  usage  constraints: 

•  Resource  Locution 

To  support  a  given  move  activity,  a  resource  must  be  at  the  activity’s  origin  location  at  its 
start  and  will  be  at  the  destination  location  at  its  finish.  Depending  on  the  location  ofthe 
resource  prior  to  its  allocation  to  this  activity,  a  supporting  positioning  activity  might  be 
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necessary  and  likewise,  depending  on  its  subsequent  obligations,  depositioning  might  be 
necessary.  As  discussed  earlier,  a  move  activity  expansion  typically  includes  provisions  for 
such  derivative  activities.  As  a  given  resource  is  assigned,  location  constraints  are  enforced 
by  appropriately  adjusting  relevant  duration  constraints. 

•  Resource  Carrying  Capacity 

A  given  move  activity  specifies  a  manifest  quantity  which,  together  with  the  carrying  ca¬ 
pacity  of  available  resources,  will  ultimately  determine  how  many  trips  will  be  required 
and  how  long  the  overall  move  will  take.  When  resources  of  a  given  type  are  allocated  to 
a  given  activity,  sibling  activity  networks  are  created  and  instantiated  to  correspond  with 
each  required  trip.  Depending  on  the  number  of  resources  actually  available,  these  trips 
may  occur  in  multiple  waves,  with  some  resources  being  reused. 

3.4  Mixed- Initiative  Resource  Management 

The  above  constraint  management  and  scheduling  procedures  are  configured  to  provide  a  range 
of  interactive  and  semi-automated  resource  management  capabilities  within  Comirem.  Gen¬ 
erally  speaking,  Comirem  is  designed  to  provide  a  graphical  spreadsheet-style  model  of  user- 
system  interaction,  where  the  user  opportunistically  manipulates  various  planning  and  plan 
data  (e.g.,  requirements  and  capabilities,  resource  allocation  decisions)  and  the  consequences 
of  user  changes  (e.g.,  updated  sets  of  decision  options,  instantiation  of  implied  derivative  activ- 
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ity  networks)  are  made  apparent.  The  user  can  selectively  employ  more  automated  capabilities 
(e.g.,  requesting  resource  feasibility  checking  and  auto-scheduling  for  larger  fragments  of  the 
developing  plan),  in  which  case  the  resulting  “propagation  of  effects”  of  a  user  action  can  be 
significant  (and  may  involve  heuristic  choice).  Also  following  the  spreadsheet  metaphor,  the 
user  can  change  her  mind  at  any  point,  retract  one  or  more  prior  actions,  and  resume  the  plan¬ 
ning  process  in  another  direction. 

The  current  planning  focus  in  Comirem  is  on  the  problem  of  assigning  resources  to  a  (possi¬ 
bly  evolving)  plan  and  then  managing  these  assignments  as  execution  ofthe  plan  moves  forward. 
Input  to  the  system  takes  the  form  of  an  initial  plan  sketch  that  specifies,  at  some  level  of  abstrac¬ 
tion,  the  actions  necessary  to  accomplish  certain  end  goals  for  a  given  scenario.  Figure  28  gives 
an  example  ofthe  type  of  problem  of  interest.  It  graphically  depicts  a  plan  for  evacuating  citizens 
from  an  embassy  in  a  foreign  country.  The  same  plan  is  shown  from  an  activity-centered  per¬ 
spective  in  Figure  29.  Following  an  initial  staging  activity,  the  Embassy-Rescue  plan  consists 


Figure  28:  Embassy  rescue  scenario 

basically  of  three  parallel  threads:  one  aimed  at  securing  a  local  airport  for  eventual  extrac¬ 
tion  (Sei  ze-Ai  rport),  one  concerned  with  blocking  the  advance  of  hostile  forces  to  the  airport 
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Figure  29:  Embassy-Rescue  plan 


(Defend-Bri  dge)  and  a  final  thread  aimed  at  transferring  citizens  from  the  embassy  (where  they 
have  congregated)  to  the  airport  (Evacuate-Embassy).  Once  at  the  airport,  everyone  is  flown 
out  and  returned  home. 

Several  of  the  activities  in  this  plan,  specifically  the  moves,  require  various  transport  and 
combat  capabilities.  Input  constraints  also  specify  initial  assumptions  concerning  the  locations 
and  availability  of  various  air  and  land  assets.  Additionally,  each  thread  of  the  plan  presumes 
an  independent  taskforce,  which  must  be  configured  from  available  personnel.  Starting  from 
the  initial  plan,  Comirem  assists  the  user  in  allocating  resources  to  input  activities.  In  cases 
where  feasible  assignment  entails  the  generation  of  resource  support  plans  (e.g.,  for  positioning 
an  aircraft  to  the  location  where  it  is  needed),  Comirem  adjusts  these  activities  accordingly  as 
specific  resource  assignments  are  considered.  If  the  overall  process  is  successful,  the  result  is 
a  detailed  plan  where  each  activity  is  assigned  the  resources  it  requires  and  is  designated  to 
execute  in  a  specified  finite  time  interval. 

Using  the  Embassy-Rescue  plan  as  a  reference,  we  now  summarize  the  key  functional  capa¬ 
bilities  provided  in  Comirem  for  intelligently  assisting  the  user  in  addressing  resource-allocation 
problems  ofthis  nature. 

3.4.1  Interactive  Planning  and  Resource  Allocation 

The  problem  at  earlier  stages  of  the  planning  process  is  one  of  reconciling  an  input  concept  of 
operations,  represented  as  a  set  of  inter-related  activities,  with  a  heterogeneous  set  of  available 
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resources.  Activities  specify  required  capabilities,  which  may  be  provided  by  one  or  more  types 
of  available  resources.  Figure  30  shows  the  Embassy-Rescue  plan  as  presented  by  the  web- 
browser-based  Comirem  GUI.  Here  we  are  looking  at  a  “vector”  display  of  the  plan,  where  the 
background  horizontal  bars  represent  locations  overtime,  diagonal  lines  represent  moves  from 
place  to  place,  and  horizontal  lines  represent  events  occurring  at  a  location. 


Figure  30:  Annotated  Comirem  GUI  display  of  Embassy-Rescue  plan 

Given  this  input  state,  Comirem  provides  the  following  support  for  refining  and  sourcing  a 
given  plan: 

•  Option  Generation 

For  each  unassigned  activity  in  the  plan,  Comirem  maintains  the  current  set  of  feasible 
allocation  options.  Figure  31  shows  the  situation  for  the  initial  posi  ti  on-for-i  nsertion 
activity  of  the  plan.  There  are  two  feasible  choices:  three  MH-47  helicopters  or  nine  MH- 
60  helicopters.  The  numbers  required  reflect  the  size  of  the  manifest  to  be  transported 
(i.e.,  the  number  of  troops  in  the  assigned  taskforces:  alpha  and  bravo)  and  the  respective 
carrying  capacities  of  the  assets;  the  durations  given  reflect  the  quantities  available,  their 
speed,  and  their  locations. 
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Figure  31 :  Option  generation  and  selection 


•  Visualization  of  Decision  Impact 

As  the  user  elects  to  commit  to  a  given  option,  impact  of  this  assignment  is  reflected  in  the 
plan.  Figure  32a,  for  example,  shows  the  MH-47  assignment  (where  three  helicopters  will 
fly  in  tandem).  Since  these  assets  are  initially  based  at  home-station,  there  is  no  need  for 
a  positioningflight;  buta  depositioningflight  has  been  added.  In  Figure  32b  the  impact  of 
alternatively  choosing  the  MH-60’s  is  shown.  In  this  case  availability  constraints  force  the 
activity  to  be  performed  in  two  waves  of  seven  and  two  trips  (and  hence  the  significantly 
longer  duration).  A  comparison  of  the  utilization  of  the  three  MH-47’s  and  the  seven 
MH-60’s  is  shown  in  Figure  32c. 

Other  visual  cues  provide  information  about  the  constrainedness  of  the  current  planning 
search  space.  The  vector  display  can  be  re-colored  to  indicate  decision  criticality  (a  func¬ 
tion  of  how  many  resource  assignment  options  remain).  Similarly,  the  display  can  be 
toggled  to  show  the  degree  of  temporal  flexibility  associated  with  different  activities;  Fig¬ 
ure  32  actually  shows  the  earliest  execution  interval  of  position-for-insertion. 

•  Requirements  and  Capabilities  Editing 

Both  activity  and  resource  attributes  can  also  be  edited  to  alter  the  constraints  and  re¬ 
quirements  of  the  problem.  In  Figure  31,  the  position-for-insertion  activity  is  shown 
to  require  a  light-transport  capability  (shown  in  red),  which  maps  to  either  of  the  heli¬ 
copter  types  mentioned  earlier.  Through  selection  in  this  display,  the  user  is  free  to  adjust 
these  requirements,  either  specifying  alternative  or  additional  capabilities  or  platforms 
that  might  be  viable  to  consider.  Any  adjustments  result  in  a  corresponding  update  of 
feasible  options.  Other  timing  constraints  on  activities  (e.g.,  deadlines  or  synchronization 
points)  can  similarly  be  manipulated  to  open  up  (or  restrict)  the  set  of  options. 

Resource  attributes  can  similarly  be  manipulated  to  vary  basic  problem  assumptions.  For 
example,  the  numbers  of  resources  available  and  their  initial  locations  can  be  revised  to 
evaluate  the  consequences  of  an  alternative  deployment.  In  Figure  33  we  show  an  edit¬ 
ing  action  to  introduce  the  constraint  that  only  one  aircraft  can  be  on  the  ground  at  a 
time  at  location  stagi  ng-area  (whereas  it  had  previously  been  specified  as  unconstrained). 
Figure  34  shows  the  consequence  on  the  position-for-insertion  activity:  the  three 
MH-47  flights  now  must  unload  in  a  staggered  fashion. 
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[a]  MH-47  assignment  -  three  helicopters  make  three  trips: 


position-for-insertion:  one  wave 


[b]  MH-60  assignment  -  seven  helicopters  make  nine  trips: 


position-for-insertion:  two  waves 


[c]  Utilization: 

MH-47-005: 

MH-47-004: 

MH-47-003: 

MH-47-002: 

MH-47-001: 


UTJLLZATtOH 


MH-60-007: 

MH-60-006: 

MH-60-005: 

MH-60-004: 

MH-60-003: 

MH-60-002: 

MH-60-001: 


MH-47 

1 _ 1 

MH-60 

option 

0100Z 

option 

J'JLL^i'ON 
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J 


0100Z  0200Z 


Figure  32:  MH-47  and  MH-60  assignment  options  and  utilization  profiles  for  the  position- 
for-insertion  activity 
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PLACE  CAPACITY 


Place 

Place  Type 

Capacity 
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embassy 

wotlcing-MOG 

unconstrained 

home-station 

wotlcing-MOG 

unconstrained 

local-airport 

worfleing-MOG 

unconstrained 

staging-area 

working-MOG 

I 

1  J 

| 

SJ\ 

Figure  33:  Imposing  a  maximum-on-ground  (MOG)  constraint 


ACTIVITY  NETWORK 


0100Z 

0200Z 

home -station 

staging-area 

I  m 

HI 

■2-i 

Three  MH-47  helicopters  arriving  and 
departing  sequentially  at  staging-area 

Figure  34:  Revised  MH-47  assignment  for  the  position-for-insertion  activity  following  the 
tightening  of  the  staging-area  MOG  constraint 


•  Automated  Assignment  and  Feasibility 

The  user  can  selectively  rely  more  on  system  decision  procedures.  For  any  selected  set  of 
unassigned  activities  in  the  plan,  the  user  can  invoke  an  underlying  automatic  scheduler 
to  generate  a  feasible  assignment.  This  action  constitutes  a  check  of  the  overall  resource 
feasibility  of  the  plan  (assuming  whatever  decisions  have  been  previously  fixed  by  the  user). 
The  allocation  goals  and  preferences  that  focus  the  automated  scheduler  can  be  adjusted 
by  the  user  to  produce  different  sets  of  resource  assignments,  in  scenarios  where  overall 
resource  capabilities  contain  this  flexibility. 

•  What-lf  Analysis 

As  implied  by  much  of  the  discussion  above,  most  constraints  and  planning  decisions  are 
pliable  through  the  interface  to  allow  general  exploration  of  the  problem  and  solution 
space.  The  system  provides  a  general  ability  to  undo  any  user-level  action  (or  sequence  of 
actions)  previously  taken.  Coupled  with  the  above  described  capabilities,  this  mechanism 
provides  a  flexible,  open-ended  framework  for  what-if  analysis. 
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3.4.2  Resource  Configuration 

Complementary  capabilities  for  interactively  configuring  aggregate  resources  (taskforces  in  our 
Embassy-Rescue  scenario)  from  more  primitive  resource  objects  (in  this  case,  individual  person¬ 
nel)  are  provided  through  a  drag  and  drop  interface  as  shown  in  Figure  35.  When  a  resource 
is  added  to  an  aggregate  underdevelopment,  the  system  checks  basic  availability  constraints. 
When  an  aggregate  resource  is  assigned  to  a  thread,  this  resource  and  all  of  its  constituents  be¬ 
come  otherwise  unavailable  for  allocation  over  the  period  that  the  thread  executes.  Hence,  just 
as  in  the  case  where  primitive  resources  are  allocated,  the  potential  addition  of  a  resource  to  an 
aggregate  resource  or  the  potential  assignment  of  an  aggregate  resource  to  a  thread  may  be  in¬ 
feasible  due  to  prior  commitments,  or  likewise,  may  require  additional  sequencing  of  competing 
activities  in  the  plan. 


Figure  35:  Annotated  taskforce  composition  form 
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3.4.3  Conflict  Analysis  and  User-Oriented  Explanation 

User  acceptance  of  system  decisions  in  successful  problem-solving  episodes  and  effective  user 
involvement  in  circumstances  where  a  system  reaches  a  problem-solving  impasse  both  require 
that  a  system  be  comprehensible.  This  requirement,  in  turn,  implies  that  a  system  be  capable 
of  explaining  its  decisions  in  user-understandable  terms.  Our  previous  work  has  argued  for  the 
use  of  a  scheduling  domain  ontology  as  a  basis  for  translating  user  problem  specifications  into 
internal  system  models  [Smith  and  Becker,  1997].  Recent  work  with  Comirem  has  focused  on 
a  complementary  use  of  a  domain  ontology  to  compute  user-oriented  explanations  of  system 
decisions  and  conflicts  [  >mith  etal.,  200'  ].  The  central  idea  is  to  use  Comirem  domain  ontology 
knowledge  to  (1)  compute  the  set  of  user-relevant  and  manipulable  constraints  that  form  an 
explanation,  (2)  identify  various  constraint-relaxation  options  that  the  user  might  consider  to 
resolve  a  conflict,  and  (3)  provide  content  for  generating  user-understandable  explanations  of 
conflicts  and  possible  resolving  actions. 

Figure  36  shows  the  system’s  response  in  a  situation  where  it  has  detected  that  it  is  not 
possible  to  complete  an  activity  by  its  imposed  deadline  if  the  assigned  resource  is  used.  In 
this  case,  knowledge  relating  temporal  constraints  in  the  underlying  STP  constraint  network 
to  various  domain  level  constructs  (e.g.,  activity  and  relation  types)  is  used  to  filter  the  set  of 
constraints  found  to  be  in  conflict  by  the  temporal  constraint  propagator  and  identify  the  subset 
that  is  user  manipulable.  Once  this  subset  of  constraints  is  identified,  knowledge  associated 
with  corresponding  domain  entities  is  used  to  propose  possible  constraint  relaxation  options. 
The  user  can  then  choose  from  this  set  of  proposed  options. 

3.4.4  Execution  Management 

Finally,  Comirem  provides  additional  tools  for  managing  resources  and  resource  assignments  as 
execution  unfolds: 

•  Resource  Tracking 

A  “magboard”  Ul  display  (shown  in  Figure  37)  provides  a  geographical  visualization  of 
the  location  of  all  resources  at  any  given  point  in  time.  The  display  distinguishes  those 
resources  that  are  (1)  in-transit  from  one  location  to  another,  (2)  at  a  location  but  en¬ 
gaged  in  some  activity  (e.g.,  providing  air  cover  support,  securing  an  airport),  or  (3)  at  a 
location  and  available  for  use. 

•  Plan  Tracking 

Both  the  vector  display  of  the  plan  (and  an  additional  Gantt-based  view)  can  also  be  used 
to  visualize  the  current  state  of  execution.  As  information  about  the  actual  start  and  end 
of  activities  is  received,  the  executing  frontier  of  the  plan  is  highlighted  and  any  conflicts 
between  the  actual  and  expected  course  of  events  are  signaled. 
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Summary  of  duration  conflict: 


Negative  Cycle: 
1 40  minutes 


EFT  (Move:  w/MH-60)  EFT  (Move:  w/MH-47) 


Conflict:  Duration(Move  w/MH-47)  >  LFT(Move)  -  EST(Move) 


£>  Comirem  GUI  duration  conflict  resolution  options: 


[a] 

[b] 

[c] 


Explanation  of  duration  conflict  resolution  options: 


[a]  Override  the  domain  constraints  based  on  deeper  strategic 
information  (e.g.,  favorable  weather  conditions) 

[b]  Extend  LFT(Move)  by  1 40  minutes  to  account  for  the  MH-47 
duration  constraint 

[c]  Assign  the  faster  MH-60  resource  to  Move 


Figure  36:  A  sample  duration  conflict  and  corresponding  CoMiREM-generated  resolution  op¬ 
tions 
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Figure  37:  Annotated  Comirem  GUI  Magboard  screen  shot 
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3.5  Scheduler  Architecture 


An  overview  of  the  underlying  Comirem  system  architecture  is  presented  in  Figure  38.  The  plan¬ 
ning/scheduling  engine  is  implemented  in  Common  Lisp  [Steele  Jr.,  1990]  as  an  extension  ofthe 
platform-independent  Ozone  scheduling  framework  [  smith  etal.,  1996], 20  It  operates  together 
(i.e.,  as  a  sibling  Lisp  process)  with  a  Common  Lisp  HTTP  server,21  which  facilitates  the  trans¬ 
mission  of  either:  (1 )  dynamically  generated  HTML/XML  responses  or  (2)  files  from  disk  (e.g., 
HTML/XML  documents)  to  an  Internet  browser  client  using  standard  CGI  (Common  Gateway 
Interface),  and  is  used  to  support  both  visualization  and  interactive  development  of  plans  and 
schedules.  The  coupling  ofthe  core  planner/scheduler  with  a  web  server  provides  immediate 
interoperability  with  most  any  web  browser  (and  by  extension,  nearly  any  hardware  platform), 
and  even  more  importantly,  the  broad  range  of  existing  interactive  visualization  tools  and  appli¬ 
cations  designed  to  work  with  them.  The  Comirem  system  is  therefore  able  to  take  advantage 
ofthe  wealth  of  web-based  visualization  tools  that  already  exist  and  allow  the  user  to  interact 
with  it  using  whatever  tool  is  best  suited  for  the  present  circumstances  (e.g.,  hardware  consid¬ 
erations,  user  preference). 


Client  Processor  Host  Processor 


File  Server 


Figure  38:  Comirem  system  architecture  showing  process  and  data  flows 


20Comirem  runs  on  the  Apple  MacOS  X,  Microsoft  Windows  and  Sun  Solaris  platforms. 

21  Both  AllegroServe  in  Allegro  Common  Lisp  and  CL-HTTP  in  Macintosh  Common  Lisp  are  supported. 
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Comirem  is  presently  capable  of  interacting  with  three  different  types  of  visualization  and 
interaction  tools. 

•  A  Shockwave  application  serves  as  the  primary  user  interface  component  (see  the  Client 
Processor  on  the  left  in  Figure  38).  This  choice  reflects  an  underlying  objective  to  explore 
the  potential  of  more  modern  web-based  design  tools  for  interactive  visualization  and 
manipulation  of  plans  and  schedules.  This  application  was  built  using  Macromedia’s 
Director  program  and  the  Lingo  scripting  language,  and  is  executable  in  any  common 
web  browser  using  the  freely  available  Shockwave  plug-in  application. 

•  The  architecture  also  supports  the  use  of  standard  HTML/XML  forms  as  an  information 
display  and  input  medium.  We  envision  such  interface  components  as  being  particu¬ 
larly  necessary  in  some  mobile  circumstances,  where  screen  real  estate  and  computational 
considerations  may  prohibit  extensive  graphical  interface  capabilities.  Within  the  current 
Comirem  interface,  forms  are  provided  for  adding,  retracting  and  editing  various  plan 
constraints  and  resource  assignments. 

•  Finally,  provision  is  made  to  interact  and  interoperate  with  externally  developed  Java  ap¬ 
plets.22  In  general,  our  current  user  interface  design  perspective  is  to  de-emphasize  Java 
components  in  favor  of  an  expanded  functionality  Shockwave  application.  While  inter¬ 
operability  with  Java  applets  is  important  given  their  widespread  use  in  web  application 
environments,  our  experience  to  date  nonetheless  indicates  that  Shockwave  offers  the  po¬ 
tential  for  much  more  lightweight  software  components  (i.e.,  smaller  footprint,  no  run¬ 
time  library  support  required). 

Each  of  these  interfaces  communicates  with  the  Comirem  server  via  standard  HTTP  proto¬ 
col  (currently  HTTP/1.1).  Requests  from  browser  clients  are  encoded  as  URLs  and  transmitted 
to  the  server,  and  HTML/XML  responses  are  then  generated  (or  uploaded  from  disk)  and  re¬ 
turned  to  the  client  web  browser  using  CGI.  (Direct  peer-to-peer  socket  communication  with 
the  Comirem  server  is  also  supported,  in  case  interaction  with  an  encapsulated  Java-based  ap¬ 
plet  is  required.)  For  the  most  part,  interaction  with  the  Comirem  planner/scheduler  is  simply 
achieved  by  launching  a  web  browser  and  requesting  a  specific  web  page. 


22An  early  version  of  Comirem  relied  on  the  use  ofjava  applets  adapted  from  another  Ozone-based  system  to 
display  resource  capacities. 
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4  Interoperability  with  the  SOFTools  Environment 

Comirem  has  been  integrated  with  a  collection  of  other  tools  developed  for  the  SOF  domain, 
including  SOFTools  (an  interactive  plan-authoringtool)  and  C2PC  (an  interactive  mapping  pro¬ 
gram).  Comirem  accepts  XML-formatted  plan  data  files  from  SOFTools,  performs  resource- 
feasibility-checking  on  the  plan,  and  exports  “magboard”-style  outputdata  fordisplay  in  C2PC. 


4.1  Temporal  Plan  Editor 


SOFTools  is  a  collection  of  mission  planning  and  editing  tools  developed  by  BBN  (initially)  and 
General  Dynamics  Advanced  Information  Systems  to  allow  a  (human)  planner  to  create  and  an¬ 
alyze  plans  in  the  SOF  domain.  The  planner  establishes 
the  temporal  representations  of  a  mission  plan  and  any 
related  supporting  plans  using  SOFTools’  Temporal  Plan 
Editor  by  defining  movements  and  events  at  various  loca¬ 
tions  and  times.  These  plans  represent  a  high-level  view 
of  a  developing  plan,  in  which  the  times  are  essentially 
estimates  based  on  expected  plan  locations  and  resource 
assignments.  Interaction  with  Comirem  begins  with  the 
translation  and  import  of  the  SOFTools-generated  plan 
file,  which  permits  Comirem  to  evaluate  both  the  resource 
and  temporal  feasibility  of  the  SOFTools  plan  under  a 
range  of  resource-availability  situations. 

The  key  features  of  the  interaction  between  SOFTools  involve  the  translation  of  the  input 
data  and  the  resource  and  temporal  feasibility-checking,  summarized  below: 


Temporal  Plan  Editor  screen  shot 


•  Translation  of  input  data: 

SOFTools  allows  the  planner  to  assign  estimated  departure  and  arrival  times  to  move¬ 
ments  and  events  in  a  plan  and  to  attach  certain  resource  quantities  to  these  activities— 
without  any  consideration  of  actual  resource  availability.  There  are  no  explicit  temporal 
sequencing  constraints  and  the  anticipated  activity  durations  are  all  estimates  that  are 
based  on  expected  locations  and  typical  resource  traveling  speeds.  For  the  purpose  of  an¬ 
alyzing  this  data,  Comirem  has  been  equipped  with  a  module  that  translates— with  some 
necessary  modification— SOFTools  plan  data  into  CoMiREM-acceptable  form. 


•  Resource  and  temporal  feasibility-checking: 

Once  a  SOFTools  plan  has  been  translated  into  Comirem  format  (a  process  that  is  per¬ 
formed  automatically  whenever  a  SOFTools  plan  (scenario)  is  loaded),  Comirem  is  ideally 
suited  to  perform  the  necessary  resource  and  temporal  feasibility  checks  to  assure  that  a 
plan  is  generally  feasible  given  a  particular  resource-availability  situation.  The  following 
checks  are  performed: 


-  Resource  availability  is  evaluated  by:  (1)  ensuring  that  all  required  resources  are,  or 
will  be,  placed  at  the  locations  required  by  the  activities  to  which  they  have  been 
assigned,  and  (2)  that  sufficient  resource  capacity  is  available  to  satisfy  the  desired 
assignments. 
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-  Temporal  feasibility  is  evaluated  by  applying  a  more  strict  domain  model  to  the  esti¬ 
mated  activity  durations  that  relies  on  detailed  resource  models  and  more  accurate 
distance-based  movement-duration  calculations. 


4.2  Check  List  Editor 


Interaction  with  SOFTools’  Check  List  Editor  (CLE)  provides  an  additional  means  for  assessing 
feasibility  in  plans,  by  adding  the  possibility  of  having  to  consider  actual  execution  results. 
The  CLE  allows  planners  to  augment  a  SOFTools  plan 
with  runtime  information  that  indicates  (among  other 
things)  when  an  activity  has  begun  or  completed  execu¬ 
tion.  Comirem  is  capable  of  accepting  calltimes  (i.e.,  ac¬ 
tual  start  and  end  times  for  activities)  and  factoring  those 
times  into  its  resource  and  temporal  feasibility-checking 
routines.  Calltimes  are  treated  by  Comirem  as  hard  (i.e., 
non-relaxable)  temporal  constraints  that  compress  activ¬ 
ity  time  windows  down  to  the  absolute  minimum.  Ad¬ 
ditionally,  the  processing  of  calltimes  causes  Comirem  to 
update  its  internal  clock,  which  prohibits  it  from  recon¬ 
sidering  decisions  made  in  the  past,  and  further  tightens  Check  List  Editor  screen  shot 
the  temporal  flexibility  of  the  plan. 


^  tl'i  m*  m 


4.3  Command  and  Control  Personal  Computer 

Command  &  Control  Personal  Computer  (C2PC),  developed  by  Northrop  Grumman,  is 
teractive  mapping  application  that  provides  a  geographically  based  situational-awareness 
bility  that  can  be  used  to  track  assets  over  time  in  support 
of  operational  and  tactical  decision-making.  Comirem  in¬ 
teracts  with  C2PC  using  overlays,  which  are  data  files  that 
are  continually  monitored  byC2PC  and  (re)displayed  im¬ 
mediately  when  modified.  Overlay  files  allow  the  chang¬ 
ing  positions  of  assets  to  be  displayed  in  animated  form 
over  time.  Using  its  own  Magboard  display  (see  Figure  37, 

Section  3.4.4  (Execution  Management),  page  57,  and  Sec¬ 
tion  B.4.4),  Comirem  can  be  made  to  generate  a  sequence 
of  overlay  files  at  specified  time  increments  so  that  C2PC 
can  display  the  plan  as  its  execution  is  simulated. 


an  in- 
capa- 


C2PC  screen  shot 
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5  Demonstration  Problems 


As  part  of  the  evaluation  process  for  Comirem,  two  different  SOF-type  scheduling  problem  sce¬ 
narios  have  been  developed  to  help  assess  its  modeling  and  scheduling  capabilities.  The  first, 
Embassy  Rescue  (developed  within  the  Intelligent  Coordination  and  Logistics  Laboratory  at 
CMU  and  introduced  earlier  in  Section  3.4,  Mixed-Initiative  Resource  Management),  involves 
a  rescue  mission  to  a  U.S.  embassy  in  a  foreign  country  using  mainly  air  assets.  The  second, 
Exotic  Dancer  (provided  by  the  Active  Templates  program  via  the  SOFTools  Temporal  Plan  Ed¬ 
itor),  involves  a  synchronized  attack  on  two  remote  targets  using  a  combination  of  air,  sea  and 
land  assets.  Both  of  these  scenarios  are  described  in  this  section.  Section  5.1  presents  some 
common  type  definitions  shared  by  both  problems.  Section  5.2  describes  the  Embassy  Rescue 
scenario,  and  Section  5.3  describes  the  Exotic  Dancer  scenario. 

One  major  difference  between  the  two  scenarios  is  the  data-loading  process.  For  Embassy 
Rescue,  the  datafiles  are  loaded  directly  without  any  additional  translation.  For  Exotic  Dancer, 
however,  since  the  scenario  data  comes  directly  from  XML  output  files  generated  by  SOFTools’ 
Temporal  Plan  Editor,  an  additional  translation  phase  must  be  performed  to  first  generate  a 
scenario- pi  an.  xml  file  that  is  amenable  to  Comirem.  For  both  scenarios,  corresponding  situa¬ 
tion  data  files  defining  the  necessary  resource  and  activity  types,  capabilities  (if  necessary),  and 
resource  instances  have  been  established  to  facilitate  system  evaluation. 

Additional  differences  between  the  two  scenarios  involve:  (1 )  the  use  of  constraints,  includ¬ 
ing  temporal  sequencing  constraints  and  earliest  and  latest  start  and  finish  constraints  on  activ¬ 
ities,  (2)  the  use  of  capabilities  as  a  means  of  connecting  required  resources  to  activities,  and  (3) 
the  use  of  both  capacitated  and  uncapacitated  place  component  resources.  These  differences 
are  described  in  greater  detail  as  part  of  the  discussion  of  each  scenario. 


5.1  Common  Definitions 

Both  the  Embassy  Rescue  and  Exotic  Dancer  scenarios  rely  heavily  on  the  use  of  air  assets  for 
transporting  personnel.  A  shared  activity  type  supports  the  sourcing  of  aircraft,  and  the  shared 
resource  types  include  an  :organic  FOOT  resource  and  two  common  helicopter  (i.e.,  ROTOR) 
types. 


5.1.1  Activity  Types 

The  RESOURCE-SOURCING  wrapper  activity  type  presented  in  Figure  39  and  discussed  extensively 
in  Section  3. 2. 1.1  (Hierarchical  Activity  Networks),  facilitates  the  sourcing  of  available  mobile 
resources  (i.e.,  aircraft  and  seacraft)  from  elsewhere  in  the  environment.  The  wrapper  surrounds 
a  nexus  activity  (the  :  chi  Id  activity  referenced  in  Figure  39)— typically  a  move  activity  of  some 
sort— with  a  preceding  positioning  leg  (a  move  activity)  and  a  succeeding  depositioning  leg  (an¬ 
other  move  activity)  that  can  be  used  for  the  sourcing  and  return  of  the  resource.  The  instanti¬ 
ated  RESOURCE-SOURCING  wrapper  will  permit  Comirem  to  look  for  candidate  resources  accord¬ 
ing  to  how  the  actual  nexus  activity  is  defined— i.e.,  based  on  the  values  of  its  resource-ori  gi  n 
and  resource-destination  variables  (specified  in  its  initargs  tag).  If  these  variables  are  set 
to  specific  places  or  locations,  then  only  resources  positioned  at,  and  able  to  return  to  those 
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locations,  are  feasible.  If  these  variables  are  left  unbound  (i.e.,  free),  then  resources  from  any¬ 
where  in  the  environment  may  be  used. 

5.1 .2  Resource  Types 

Figure  40  presents  the  XML  specifications  forthree  resource  types  shared  by  the  Embassy  Rescue 
and  Exotic  Dancer  scenarios.  The  two  helicopter  types,  MH-47  and  MH-60,  are  common  SOF  air 
assets.  The  FOOT  resource  is  universal,  representing  movement  by  foot  (and  making  use  of  the 
: organic  model  type).  In  both  scenarios,  a  UNIVERSAL- FOOT  resource  is  instantiated  from  this 
type,  providing  unlimited  capacity. 

5.2  Embassy  Rescue 

As  described  in  Section  3.4  (Mixed-Initiative  Resource  Management)  and  illustrated  in  Fig¬ 
ures  28  (page  48)  and  29  (page  49),  the  Embassy  Rescue  scenario  describes  a  rescue  mission 
that  culminates  in  the  evacuation  of  personnel  from  a  U.S.  embassy  on  foreign  soil,  and  con¬ 
sisting  of  three  initially  separate  threads  that  converge  at  the  end.  The  three  threads  behave  as 
follows: 

1.  Defend-Bridge  -  A  taskforce  (alpha),  deploys  to  a  strategic  bridge  location  within  enemy 
territory  to  defend  a  temporarily  enemy-control  led  airport  against  further  enemy  advance, 
before  moving  to  the  newly  secured  airport  for  final  evacuation. 

2.  Seize-Airport  -  A  taskforce  (bravo),  deploys  to  the  enemy-controlled  airport,  overtakes  en¬ 
emy  forces  there,  and  then  prepares  for  the  evacuation  of  the  rescued  embassy  personnel 
and  all  three  taskforces. 

3.  Evacuate-Embassy  -  A  taskforce  (charlie),  deploys  to  the  embassy,  secures  it,  and  then  evac¬ 
uates  all  personnel  to  the  recently  secured  airport  for  final  evacuation. 

Once  all  of  the  personnel  and  taskforces  have  assembled  at  the  airport,  a  single  movement 
(in  multiple  waves)  evacuates  everyone  back  to  the  home  station.  And  throughout  the  main 
body  of  the  plan,  a  single  provi  de-cover-fi  re  activity  does  precisely  that. 

The  internal  representation  of  this  plan  is  presented  in  Figure  41 ,  showing  all  of  the  activities 
and  locations,  derivative  sourcing  legs,  temporal  sequencing  constraints,  cargo  manifests,  re¬ 
quired  durations  and  resource  requirements.  Places  in  the  plan  (some  of  which  are  repeated  for 
the  sake  of  clarity)  are  identified  along  the  y-axis,  extending  horizontally  across  the  figure.  The 
10-hour  plan  horizon  extends  across  the  x-axis.  Activities  are  drawn  in  green  (for  moves)  and 
yellow  (for  events),  with  derivatives  drawn  in  dark  blue.  The  activities  are  labeled  with  boxes 
showing  their  required  capability  or  resource  class  at  the  top,  the  name  of  the  activity  in  the 
middle,  and  the  manifest,  taskforce  identification,  and  sometimes  the  required  duration  at  the 
bottom.  The  temporal  sequencing  constraints  are  drawn  with  red  annotated  arrows. 
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Resource  Origin 
Resource  Destination 
Origin 
Destination 


RESOURCE-SOURCING 

[aggregate] 


<type> 

<wrapper  name=,,resource-sourcing"> 

<vari abl es> resou rce-o ri gi n  resource-desti nationc/vari ables> 
<i  nputs>or7'g7'n  desti nation</i  nputs> 

<decomposi tion> 

<chi Id-spec  name=" posit  ion ing”> 

<type- ref >move</type- ref> 

<i ni targs> 

<initarg  name=Morigi nM> 

<sl  ot>resource-origi n</s~\  ot> 

</i ni targ> 

<initarg  name="desti nati on"> 

<keyword>or7gf7n</keyword> 

</initarg> 

</initargs> 

</child-spec> 

<chi Id-spec  name=" deposit ioning"> 

<type- ref >move</type- ref> 

<i nitargs> 

<initarg  name=Morigi nM> 

<keyword>c/est7'nat7on</keyword> 

</i ni targ> 

<initarg  name="desti nati on"> 

<keyword> resource-des t i nat7on</keyword> 

</i ni targ> 

</initargs> 

</child-spec> 

</decomposi ti on> 

<constrai nts> 

<constrai nt> 

<type-ref>successor</type-ref> 

<f rom>posi tioni ng</f rom> 

<to>:child</to> 

<ubxi  ntervalxmi  nutes>0</mi  nutesx/i  ntervalx/ub> 
</constrai nt> 

<constrai nt> 

<type-ref>successor</type-ref> 

<f rom> : chi  1 d</f rom> 

<to>deposi ti oni ng</to> 

<ubxi  ntervalxmi  nutes>0</mi  nutesx/i  ntervalx/ub> 
</constrai nt> 

</constrai nts> 

</wrapper> 

</type> 


Figure  39:  Structure  and  XML  specification  of  the  RESOURCE-SOURCING  wrapper  activity  type 
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<type> 

<aircraft  name="MH-47M> 

<descri ption> 

Chinook:  infiltration,  exfil¬ 
tration,  air  assault,  resupply 
and  sling  operations 
</descri ption> 

<model -type>ROTOR</model -type> 
<speed  uni ts="mphM>177</speed> 
<configurations> 

configuration  name=" :default"> 
cargo  max=M55M>PAX</cargo> 
</configuration> 

</conf i gurati  ons> 

</ai rcraft> 

</type> 


<type> 

<aircraft  name=MMH-60"> 

<descri ption> 

Black  Hawk:  infiltration,  exfil¬ 
tration,  resupply  of  special  op¬ 
erations  forces,  and  CSAR 
</descri pti on> 

<model -type>ROTOR</model -type> 

<speed  uni ts=Mmph">184</speed> 

<confi gurati ons> 

configuration  name=" :defaul t"> 
cargo  max=M14M>PAX</cargo> 
</conf i gu  rati on> 

<confi gurati on 

name="close-ai r-support"> 
cargo  max=MlM>MUNITIONS</cargo> 
</conf i gu  rati on> 

</confi gurati ons> 

</ai rcraft> 

</type> 

<type> 

<landcraft  name="FOOT"> 

<model -type> : organi c</model -type> 
<speed  uni ts=Mmph">4</speed> 
</landcraft> 

</type> 


Figure  40:  XML  specifications  of  shared  resource  types 


The  Embassy  Rescue  scenario  is  notable  for  a  number  of  reasons,  alluded  to  earlier: 


1 .  Temporal  sequencing  constraints: 

All  of  the  activities  in  the  plan  are  free  to  shift  temporally  within  a  10-hour  scheduling 
horizon.  The  necessary  synchronization  of  activities  is  achieved  using  temporal  sequencing 
constraints,  such  as  successor,  same-start  and  same-fi  ni  sh,  without  any  ref-hours  or 
anchors.  These  constraints  also  ensure  that  the  provi de-cover-fi re  activity  properly 
encompasses  its  dependent  plan  activities. 

2.  Capabilities: 

A  number  of  the  resource  requirements  for  activities  in  the  plan  rely  on  user-defined 
domain-specific  capabilities  (e.g.,  light-transport,  air-drop)  instead  of  specific  re¬ 
source  classes. 

3.  Capacitated  and  uncapacitated  place  component  resources: 

Capacity  for  aircraft  at  the  embassy  is  provided  through  two  capacitated  world  ng-MOG 
components  (embassy-yard-1  and  embassy-yard-2),  one  of  which  must  be  secured  by 
each  aircraft  doing  any  loading  or  unloading  of  cargo  on  the  site.  Capacity  for  aircraft 
loading  and  unloading  elsewhere  in  the  plan  is  represented  using  uncapacitated  (i.e.,  infinite 
capacity)  components,  such  as  at  the  enemy  airport  and  home  station. 
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Embassy  Rescue: 


Figure  41 :  Embassy-Rescue  activity  network 
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5.2.1  Activity  Types 

The  Embassy  Rescue  domain  utilizes  five  activity  types:  the  load-step  and  unload-step  events 
for  handling  cargo,  the  ai  rl  i  ft  and  ai  rdrop  aggregate  activities  for  moving  cargo  (in  this  case, 
by  air),  and  the  event-w-sourci  ng  wrapper  activity  that  is  used  to  represent  a  patrol  activity 
such  as  the  aforementioned  provi de-cover-fi re.  The  following  subsections  describe  these 
types  in  further  detail. 


5.2.1 .1  Cargo  Load  and  Unload 

Cargo  loading  and  unloading  is  handled  by  means  of  the  load-step  and  unload-step  event 
types,  respectively.  The  XML  specifications  for  both  are  shown  in  Figure  42.  Each  basically 
requires  a  sufficient  capacity  of  a  worki  ng-MOG  resource  class  instance,  which  refers  to  an  area 
of  some  kind  that  can  accommodate  the  loading  or  unloading  of  cargo  from  a  resource.  The 
AIRCRAFT  cargo  type  is  used  (currently)  to  indicate  the  maximum  capacity  of  a  worki  ng-MOG 
resource  instance  (which,  in  Embassy  Rescue,  is  1 ). 


<type> 

<event  name="load-step"> 

<requi rements> 

<requi rement> 

<resource-class>worki ng-MOG</resource-cl ass> 
</ requi rement> 

</requi rements> 

</event> 

</type> 

<type> 

<event  name="unload-step"> 

<requi rements> 

<requi rement> 

<resource-class>worki ng-MOG</resource-cl ass> 
</requi rement> 

</ requi rements> 

</event> 

</type> 


Figure  42:  XML  specification  of  Embassy-Rescue  cargo-[un]loading  activity  types 


5.2.1. 2  Airlift 

The  ai  rl  i  ft  activity  type  defines  an  activity  network  structure  similar  to  that  of  the  RESOURCE- 
SOURCING  wrapper  described  in  Section  5.1.1  (Activity  Types),  except  that  instead  of  wrapping 
positioning  legs  around  a  nexus  activity,  the  ai  rlift  activity  expands  into  three  subactivities: 
a  load-step,  a  basic  move,  and  an  unload-step.  The  worki  ng-MOG  resource  classes  required 
by  the  (un)load  steps  must  come  from  the  ori gi  n  location  for  load-step,  and  from  the  des- 
ti  nation  location  for  unload-step.  A  summary  of  the  ai  rlift  activity  type  is  provided  in 
Figure  43. 
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<type> 

<move  name="airl ift"> 

<decomposi tion> 

<child-spec> 

<type- ref> 1 oad-step</ type- ref> 

<i ni targs> 

<i ni targ  name=Mpl ace"xsl ot>ori gi n</sl otx/i ni targ> 
</i ni targs> 

</child-spec> 

<child-spec> 

<type- ref>move</type- ref > 

<i ni targs> 

<initarg  name="ori gi n"> 

<sl ot>ori gi n</sl ot> 

</initarg> 

<initarg  name=Mdesti nationM> 

<sl ot>desti nati on</sl ot> 

</i ni targ> 

</i ni targs> 

</child-spec> 

<child-spec> 

<type- ref>unload-step</type- ref > 

<i ni targs> 

<initarg  name="pl ace"> 

<sl ot>desti nati on</sl ot> 

</i ni targ> 

</i ni targs> 

</chi ld-spec> 

</decomposi ti on> 

<constrai nts> 

<constrai nt> 

<type-ref>successor</type-ref> 

<f  rom-type>7oac/-step</f  rom-type> 
<to-type>move</to-type> 

<ubxi  ntervalxmi  nutes>0</mi  nutesx/i  ntervalx/ub> 
</constrai nt> 

<constrai nt> 

<type-ref>successor</type-ref> 

<f rom-type>move</f rom-type> 
<to-type>unload-step</to-type> 

<ubxi  ntervalxmi  nutes>0</mi  nutesx/i  ntervalx/ub> 
</constrai nt> 

</constrai  nts> 

</move> 

</type> 


Figure  43:  Structure  and  XML  specification  of  the  ai  rl  i  ft  activity  type 
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5. 2.1. 3  Airdrop 

The  airdrop  activity  type,  summarized  in  Figure  44,  defines  an  activity  network  nearly  identical 
to  that  of  ai  rl i ft,  except  that  the  unload-step  is  removed.  The  airdrop  activity  models  a 
fast-rope  style  of  aerial  movement  where  personnel  and/or  cargo  are  deplaned  while  an  aircraft 
is  still  airborne.23 


<type> 

<move  name=MairdropM> 

<decomposi tion> 

<child-spec> 

<type- ref > load-step</type- ref > 

<initargs> 

<i  ni targ  name="pl ace"xsl ot>ori gi  n</sl otx/i  ni targ> 
</i ni targs> 

</child-spec> 

<child-spec> 

<type- ref>move</type- ref> 

<initargs> 

<initarg  name="ori gi n"> 

<slot>origi n</slot> 

</initarg> 

<initarg  name="desti nati on"> 

<sl ot>desti nati on</sl ot> 

</i ni targ> 

</i ni targs> 

</child-spec> 

</decomposi ti on> 

<constrai nts> 

<constrai nt> 

<type-ref>successor</type-ref> 

<f rom-type> load-step</f rom-type> 
<to-type>move</to-type> 

<ubxi  ntervalxmi  nutes>0</mi  nutesx/i  ntervalx/ub> 
</constrai nt> 

</constrai nts> 

</move> 

</type> 


Figure  44:  Structure  and  XML  specification  of  the  ai  rdrop  activity  type 


23The  term  fast-rope  describes  a  rapelling  method  for  deploying  troops  and  equipment  by  dropping  them  down 
ropes  that  hang  from  low-flying  rotor  aircraft. 
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5.2.1 .4  Event-w-Resource-Sourcing 

The  event-w-sourci ng  activity  type  is  an  event  with  a  RESOURCE-SOURCING  wrapper  (from 
Figure  39)  that  is  used  to  represent  a  patrol  or  support  mission  that  involves  a  stationary  orbit 
around  a  fixed  location,  in  which  case  it  can  basically  be  treated  as  an  event  occurring  at  a 
single  place.  The  RESOURCE-SOURCING  allows  the  resource  to  be  sourced  from  elsewhere.  The 
XML  specification  for  event-w-sourci  ng  is  presented  in  Figure  45. 


<type> 

<event  name="event-w-sourcingM> 

<vari abl es>resource-ori gi n  resource-desti nati on</vari abl es> 
<wrappers> 

<wrapper  name="resource-sourci ng"> 

<i ni targs> 

<i ni targ  name="resource-ori gi nM> 

<sl  ot> resource-ori gi n</sl  ot> 

</i ni targ> 

<i ni targ  name=" resource-desti nati on"> 

<slot> resource-desti nati on</slot> 

</initarg> 

<i  ni  targ  name="ori  gi  n"xsl  ot>pl  ace</sl  otx/i  ni  targ> 

<i  ni  targ  name="desti  nati  on"xsl  ot>pl  ace</sl  otx/i  ni  targ> 
</ini targs> 

</wrapper> 

</wrappers> 

</event> 

</type> 


Figure  45:  XML  specification  of  the  event-w-sourci  ng  activity  type 


5.2.2  Activity  Instances 

Figure  46  presents  a  sampling  of  XML  specifications  for  the  Embassy  Rescue  plan  of  activity 
instances  (on  the  right)  and  the  constraint  instances  (on  the  left)  that  link  them  together. 

5.2.3  Resource  Types 

In  addition  to  the  MH-47  and  MH-60  aircraft  described  in  Section  5.1.2  (Resource  Types),  the 
Embassy  Rescue  scenario  makes  use  of  three  additional  aircraft  types:  the  AC-130U,  MC-130H 
and  C-141.  It  also  uses  the  worki  ng-MOG  component  resource  class,  as  indicated  by  the  load- 
step  and  unload-step  activity  types  shown  in  Figure  42.  The  XML  specifications  for  each  of 
these  four  resource  types  are  shown  in  Figure  47. 

5.2.4  Capabilities 

The  capabilities  used  in  the  Embassy  Rescue  scenario  are  presented  in  Figure  48. 

5.2.5  Resource  Instances 

The  resource  instances  available  for  the  Embassy  Rescue  scenario  are  summarized  in  Table  9. 
The  left  side  of  the  figure  lists  all  of  the  mobile  resources  in  the  standard  Embassy  Rescue  sit¬ 
uation,  indicating  how  many  are  available  and  at  what  initial  location  (i.e.,  place).  On  the 
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right  side  of  the  figure,  the  place  components  (i.e.,  those  providing  worki  ng-MOG  capacity)  are 
identified.  Note  that  three  places:  home-station,  local -ai  rport,  and  staging-area  each 
provide  unlimited  worki  ng-MOG  capacity,  while  the  embassy  provides  only  two  units  of  capacity, 
indicating  that  the  processing  of  aircraft  within  the  embassy  is  limited  to  just  two  aircraft  at  a 
time. 


Table  9:  Embassy-Rescue  resource  instances 


Resource 

Type 

Number  of 
Instances 

Initial  Location 

Place 

Component 

Type 

Capacity 

AC-130U 

1 

home-station 

air-corridor 

C-141 

2 

home-station 

bridge 

FOOT 

DO 

n/a 

embassy 

working-MOG 

2 

MC-130H 

5 

home-station 

home-station 

working-MOG 

DO 

MH-47 

5 

home-station 

local-airport 

working-MOG 

DO 

MH-60 

7 

home-station 

staging-area 

working-MOG 

DO 
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Deploy  to  Airport 


<i nstance> 

<constraint> 

<type- ref > be  fore</ type- ref > 

<f rom>depl oy-to-ai rport</f rom> 

<to>secure-ai rport</to> 
</constrai nt> 

</i nstance> 


Secure  Airport 


<i nstance> 

<activity  name="depl oy-to-ai rportM> 

<type-ref>ai rdrop</type-ref> 

<descri ption> 

Deploy  Taskforce  BRAVO  to  airport 
</descri ption> 

<ori gi n>stagi ng-area</ori  gi  n> 

<desti nation>local -ai rport</desti nation> 

<wrappers> 

<wrapper  name=" resource-sourci ng"> 

<i ni targs> 

<i ni targ  name="ori gi n"xslot>ori gi n</slotx/i ni targ> 
<i ni targ  name="desti nati on"> 

<sl ot>desti nati on</sl  ot> 

</i nitarg> 

</i ni targs> 

</wrapper> 

</wrappers> 

<mani fest> 

<mani fest-entry> 

<cargo  count="64">PAX</cargo> 

</mani fest-entry> 

</mani fest> 

<requi rements> 

<requi rement> 

<capabi 1 i ti es>ai r-drop</capabi  1  i  ti  es> 

</requi rement> 

</requi rements> 

</acti vi ty> 

</i nstance> 

<i nstance> 

<activity  name="secure-airportM> 

<type- ref >event</type- ref > 

<descri ption> 

Establish  control  of  local -ai rport 
</descri ption> 

<pl ace>l ocal -ai rport</pl  ace> 

<du  rati  onxi  nte  rval  xhou  rs>2</hou  rsx/i  nte  rval  x/du  rati  on> 
</activity> 

</i nstance> 


<i nstance> 

<constraint> 

<type- ref >before</type- ref > 
<f rom>secure-ai rport</f rom> 
<to> 

evacuate-embassy 

retreat-to-ai  rport 
p repare- for-extracti  on 

</to> 

</constrai nt> 

</i nstance> 


Evacuate  Embassy 


<i nstance> 

<activity  name="evacuate-embassy"> 

<type- ref >ai rl i f t</type- ref> 

<descri ption> 

transport  AmCits  to  local -ai rport  for  extraction 
</descri ption> 

<ori gi n>embassy</ori gi n> 

<desti nati on>l ocal -an  rport</desti  nati on> 

<wrappers> 

<wrapper  name=" resource-sourci ng"> 

<i ni targs> 

<i  ni  targ  name="ori  gi  n"xslot>ori  gi  n</slotx/i  ni  targ> 
<i ni targ  name="desti nati on"> 

<sl ot>desti nati on</sl  ot> 

</i nitarg> 

</i ni targs> 

</wrapper> 

</wrappers> 

<requi rements> 

<requi rement> 

<capabi 1 i ti es>l i ght-t ransport</capabi 1 i ti es> 

</requi rement> 

</requi rements> 

<mani fest> 

<mani fest-entry> 

<cargo  count="274">PAX</cargo> 

</mani fest-entry> 

</mani fest> 

</acti vi ty> 

</i nstance> 


Figure  46:  XML  specifications  for  select  Embassy-Rescue  activity  and  constraint  instances 
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<type> 

<aircraft  name="AC-130U,,> 

<descri pti on> 

Gunship:  close  air  support, 
air  i interdiction ,  and  force  protection 
</descri ption> 

<model -type>FIXED-WING</model -type> 

<speed  uni ts="mph">374</speed> 

<confi gurations> 

configuration  name=" : default"  op="or"> 
<cargo  max="40">PAX</cargo> 
cargo  max="l">ARMS</cargo> 
</configuration> 

<confi gurati on  name="close-ai r-support"> 
cargo  max="5">MUNITI0NS</cargo> 
</configuration> 

</confi gurati ons> 

</ai rcraft> 

</type> 

<type> 

<aircraft  name="C-141"> 

<descri pti on> 

Star! 7  fter :  cargo  and  troop  support 
</descri ption> 

<model -type>FIXED-WING</model -type> 

<speed  uni ts="mph">500</speed> 
<configurations> 

confi gurati on  name=" : default"  op="or"> 
cargo  max="200">PAX</cargo> 
cargo  max="6">PALLETS</cargo> 

</conf i gurati on> 

<confi gurati on  name="heavy-transport"> 
cargo  max="200">PAX</cargo> 

</conf i gurati on> 

</confi gurati ons> 

</ai rcraft> 

</type> 


<type> 

<aircraft  name="MC-130H"> 

<descri pti on> 

Combat  Talon  II:  infiltration, 
exfi  It rati  on ,  and  resupply  of 
special  operations  forces 
</descri ption> 

<model -type>FIXED-WING</model  -type> 

<speed  uni ts="mph">374</speed> 
<configurations> 

confi gurati on  name=" : default"  op="or"> 
cargo  max="92">PAX</cargo> 
cargo  max="5">PALLETS</cargo> 

</confi gurati on> 

<confi gurati on  name="heavy-transport"> 
cargo  max="92">PAX</cargo> 

</confi gurati on> 

<confi gurati on  name="ai r-drop"> 
cargo  max="64">PAX</cargo> 

</confi gurati on> 

</confi gurati ons> 

</ai rcraft> 

</type> 


<type> 

<component  name="working-MOG"> 

<descri ption> 

Workspace  for  loading,  offloading , 
and  servicing  aircraft 
</descri ption> 

<confi gurations> 

configuration  name=" :default"> 
<cargo  max="l">AIRCRAFT</cargo> 
<confi gurati on> 

</confi gurati ons> 

</component> 

</type> 


Figure  47:  XML  specifications  of  Embassy-Rescue  resource  types 
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<capabi 1 i ty  name="heavy-transport"> 

<capabl e-types>MC-130H  C-141</capabl e-types> 
<type- ref>move</type- ref> 

</capabi 1 i ty> 

<capabi 1 i ty  name="l ight-transport"> 

<capabl e-types>MH-60  MH-47</capabl e-types> 
<type- ref>move</type- ref> 

</capabi 1 i ty> 

<capability  name="air-drop"> 

<capabl e-types>MH-60  MC-130H</capabl e-types> 
<type- ref>move</type- ref> 

</capabi 1 i ty> 

<capabi 1 i ty  name="close-ai r-support"> 

<capabl e-types>AC-130U  MH-60</capabl e-types> 
<type- ref>move</type- ref> 

</capabi 1 i ty> 


Figure  48:  XML  specifications  of  Embassy-Rescue  capabilities 
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5.3  Exotic  Dancer 


The  Exotic  Dancer  scenario  represents  the  other  end  of  the  spectrum  when  compared  to  Em¬ 
bassy  Rescue,  but  it  more  closely  reflects  the  look  and  feel  of  SOF  planning/scheduling  prob¬ 
lems,  owing  to  its  generation  by  the  SOFTools  application  program.  As  mentioned  earlier,  the 
Exotic  Dancer  scenario  involves  the  assault  on  two  separate  remote  targets.  The  assault  on 
Target  X  begins  with  an  aircraft  positioning  leg  from  the  home  base  (i.e.,  Tampa)  to  a  staging 
base  (i.e.,  FSB  Black),  and  then  an  infiltration  leg  using  MH-47s  to  carry  troops  and  cargo  in 
the  form  of  48  PAX  and  four  HMMWVs.  At  an  in-theater  landing  zone,  the  troops  and  cargo  are 
dropped,  and  the  attack  on  Target  X  proceeds  using  the  HMMWVs.  Following  the  attack,  exfil¬ 
tration  reverses  the  steps,  using  the  same  resources.  During  the  movements  from  FSB  B1  ack  to 
Target  X,  three  synchronized  support  missions  are  also  executed:  Escort  &  Fire  Support, 
Combat  Search  &  Rescue,  and  Fi  re  Support  (the  latter  encompassing  the  final  push  to  Tar¬ 
get  X). 

The  second  half  of  the  scenario  involves  an  independent  water-based  assault  on  Target  Y, 
which  begins  from  a  ship  at  sea  (i.e.,  AFSB  Whi  te).  The  infiltration  towards  Target  Y  involves 
two  steps,  the  first  using  two  MK-V  boats,  which  drop  their  eight  troops  into  two  CRRC  rafts  for 
a  beach  landing  at  BLS  Orange.  The  final  movement  to  Target  Y  takes  place  on  foot.  Fol¬ 
lowing  the  assault,  the  exfiltration  again  reverses  the  infiltration  steps,  and  the  troops  return 
to  AFSB  White.  Beginning  with  the  initial  movement  from  AFSB  White,  an  additional  Com¬ 
bat  Search  &  Rescue  support  mission  is  run,  and  a  Fire  Support  mission  executes  during 
the  attack  on  Target  Y. 

The  complete  Exotic  Dancer  scenario  is  summarized  in  Figure  49,  and  the  entire  plan,  as 
represented  within  Comirem,  is  presented  in  the  subsequent  three  figures.  Figure  50  shows 
the  initial  positioning  leg  from  Tampa  to  FSB  Black  and  the  extent  of  the  separate  attacks  on 
Target  X  and  Target  Y.  Figure  51  shows  the  full  attack  on  Target  X,  while  Figure  52  shows 
the  full  attack  on  Target  Y. 

It  is  important  to  reiterate  the  following  points  about  the  Exotic  Dancer  scenario: 

1 .  It  does  not  include  any  explicit  temporal  sequencing  constraints.  Each  activity  in  the  plan 
is  essentially  fixed  in  time  (the  start  and  end  times  are  all  linked  to  one  of  two  ref-hours 
for  the  plan:  H  and  N).  The  temporal  relations  between  all  activities,  including  those  that 
follow  one  another,  and  those,  like  the  support  missions,  that  encompass  others,  are  all 
implicit. 

2.  It  specifies  exactly  which  resources,  and  precisely  how  many  of  each,  are  required  by  each 
activity  in  the  plan  (i.e.,  Comirem’s  capability  mechanism  is  not  used).  Comirem  ignores 
its  own  calculations  based  on  manifest  quantities  and  resource  configurations,  and  in¬ 
stead  relies  on  the  numbers  provided  in  the  plan  (specified  using  count  attributes  in  the 
resource  requirements)  to  determine  how  many  resources  to  allocate  to  each  activity. 

The  Exotic  Dancer  scenario  illustrates  how  Comirem  can  be  used  as  a  feasibility-checking 
mechanism  for  plans  generated  within  a  SOFTools-like  program,  where  a  planner  with  signifi¬ 
cant  domain  knowledge  is  able  to  specify  a  plan  that  indicates,  in  detail,  what  activities  will  be 
executed,  and  which  particular  resources  will  be  used.  Comirem  can  then  be  called  to  determine 
whether  the  indicated  resources  are  indeed  available  in  sufficient  quantity  and  at  the  proper  lo- 
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Figure  49:  Exotic  Dancer  scenario 


cations  to  satisfy  the  intentions  of  the  planner.  In  the  event  that  an  infeasibility  is  encountered, 
the  planner  has  the  option  of  modifying  and  resubmitting  the  plan. 

An  example  of  this  problem  occurs  in  the  Exotic  Dancer  plan  as  it  currently  exists.  In  the 
attack  on  Target  Y,  the  second  leg  of  the  approach  by  sea  using  the  two  CRRC  rafts  is  initially 
allotted— by  the  planner— a  duration  of  52  minutes.  Given  the  maximum  traveling  speed  of  the 
CRRC  rafts,  which  according  to  the  domain  model  is  10  mph,  and  the  required  traveling  distance 
from  the  Rendezvous  Location  to  BLS  Orange,  which  is  32  miles,  Comirem  determines  that 
the  movement  will  actually  require  192  minutes  of  travel  time  using  the  CRRCs,  and  therefore 
that  there  is  not  enough  time  for  this  activity  to  complete  within  the  planner’s  bounds. 
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Figure  50:  Exoti  c-Dancer  activity  network  (summary  view) 
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Exotic  Dancer:  Target  X  subactivities 


Figure  51:  Exoti  c-Dancer  activity  subnetwork  (Target  X  tasks) 
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Exotic  Dancer:  Target  Y  subactivities 


Figure  52:  Exoti  c-Dancer  activity  subnetwork  (Target  Y  tasks) 
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The  planner  has  two  sets  of  options  at  this  point,  relying  on  either  modification  of  the  plan 
by  hand,  or  the  conflict-resolution  functionality  provided  by  Comirem,  as  described  in  Sec¬ 
tion  3.4.3  (Conflict  Analysis  and  User-Oriented  Explanation).  The  plan-modification  options 
are  as  follows: 

•  Modify  the  plan  by  changing  the  amount  of  time  allotted  to  the  movement  involving  the 
CRRC  rafts,  to  allow  enough  time  to  travel  the  32  miles  from  the  Rendezvous  Location 
to  BLS  Orange. 

•  Modify  the  plan  by  changing  the  specific  locations  of  the  Rendezvous  Location  and/or 
BLS  Orange,  to  shorten  the  distance  between  the  two  places. 

•  Modify  the  plan  by  attaching  a  different  resource  requirement  to  the  activity. 

The  Comirem  conflict-resolution  options  are: 

•  Override  the  domain  model  to  accept  the  viability  of  the  shorter  duration,  under  the  as¬ 
sumption  that  special  conditions  or  other  situational  knowledge  justify  it. 

•  Accept  the  longer  duration  determined  by  Comirem,  including  any  propagated  tempo¬ 
ral  changes.  Note  that  this  is  a  case  where  the  lack  of  any  explicit  temporal  sequencing 
constraints  can  be  a  problem.  Comirem  has  no  information  with  which  to  assess  addi¬ 
tional  conflicts  that  may  result  from  this  kind  of  relaxation.  As  a  result,  it  becomes  the 
responsibility  of  the  planner  to  determine  the  impact  of  this  action. 

•  Determine  whether  any  faster  resources  are  available  to  be  allocated  to  this  activity,  and 
offer  them  as  alternative  scheduling  options  to  the  user. 

Regardless  of  which  option  the  user  ultimately  takes,  Comirem  has  provided  a  valuable  ser¬ 
vice  in  assessing  the  resource-feasibility  of  the  plan  as  specified  and  offering  a  set  of  viable 
conflict-resolution  options. 

5.3.1  Activity  Types 

The  only  activity  type  utilized  in  the  Exotic  Dancer  scenario  is  the  RESOURCE-SOURCING  wrapper 
(described  in  Section  5.1.1,  Activity  Types). 

5.3.2  Activity  Instances 

Figure  53  presents  a  sampling  of  XML  specifications  of  Exotic  Dancer  plan  activity  instances. 
Note  the  use  of  count  attributes  in  the  requi  rements  tags  to  dictate  how  many  resource  in¬ 
stances  are  required  for  each  task,  and  the  explicit  sourcing  locations  sent  to  the  RESOURCE¬ 
SOURCING  wrapper  activity  by  the  FSB-Deployment  (top)  and  CSAR-Target-Y  (bottom)  activi¬ 
ties. 


5.3.3  Resource  Types 

The  Exotic  Dancer  scenario  utilizes  the  resource  types  listed  in  Figure  40,  Section  5.1.2  (Resource 
Types),  page  65,  and  the  additional  resource  types  defined  in  Figure  54. 
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FSB  Deployment  (from  TPA) 


<i nstance> 

<activity  name="M614077"> 

<di spl ay-name>FSB-Depl oyment</di spl ay-name> 

<type- ref>move</type- ref> 

<description> 

Deployment  from  TPA  to  FSB-Black  for  Target-X  assault 
</description> 

<origin>P852062</origi  n> 

<desti nation>P441277</desti nation> 

<wrappers> 

<wrapper  name="resource-sourci ng"> 

<initargs> 

<i  ni  targ  name="  resource-ori  gi  n"xval  ue>P852062</val  uex/i  ni  targ> 

<i  ni  targ  name="  resource-desti  nati  on"xval  ue>P852062</val  uex/i  ni  targ> 
<i  ni  targ  name="ori  gi  n"xsl  ot>ori  gi  n</slotx/i  ni  targ> 

<i  ni  targ  name="desti  nati  on"xsl  ot>desti  nati  on</sl  otx/i  ni  targ> 
</initargs> 

</wrapper> 

</wrappers> 

<requi rements> 

<requi rement> 

<resource-class  count="4">C-17</resource-class> 

</requi rement> 

</requi rements> 

<time-bounds-constrai nts> 

<ref-hour  name="N"  type="start"> 

1034992848 

</ref-hour> 

<ref-hour  name="N"  type="fi ni sh"> 

1035055152 

</ref-hour> 

</time-bounds-constrai  nts> 

</acti vi ty> 

</instance> 


TF-CRRC:  Landing  at  BLS 


<i nstance> 

<activity  name="M901480"> 

<di spl ay-name>TF-CRRC : BLS-Landing</di spl ay-name> 
<type- ref>move</type- ref> 

<descri ption> 

TF-CRRC  arrival  at  BLS-Orange  for  Target-X  assault 
</descri ption> 

<origi n>P152969</ori  gi  n> 

<desti nation>P484554</desti nation> 

<requi rements> 

<requi rement> 

<resource-class  count="2">CRRC</resource-cl ass> 
</requi rement> 

</requi rements> 

<manifest> 

<mani fest-entry> 

<cargo  count"8">PAX</cargo> 

</mani fest-entry> 

</manifest> 

<time-bounds-constrai  nts> 

<ref-hour  name="H"  type="start"> 

1035080990 

</ref-hour> 

<ref-hour  name="H"  type="fi ni sh"> 

1035084494 

</ref-hour> 

</time-bounds-constrai nts> 

</acti vi ty> 

</i nstance> 


Combat  Search  &  Rescue:  Target-Y 


<i nstance> 

<acti vi ty  name="M18300-M951819"> 

<di spl ay-name>CSAR-Target-Y</di spl  ay-name> 

<type- ref>event</type- ref> 

<capabi 1 i ty-type>move</ capabi 1 i ty-type> 

<descri ption> 

Combat  Search  and  Rescue  for  Target-Y 
</descri ption> 

<pl ace>P2  5  5811</pl ace> 

<wrappers> 

<wrapper  name=" resource-sourci ng"> 

<initargs> 

<i  ni  targ  name="  resource-ori  gi  n"xval  ue>P569440</val  uex/i  ni  targ> 

<i  ni  targ  name="  resource-desti  nati  on"xval  ue>P569440</val  uex/i  ni  targ> 
<i  ni  targ  name="ori  gi  n"xsl  ot>pl  ace</sl  otx/i  ni  targ> 

<i  ni  targ  name="desti  nati  on"xsl  ot>pl  ace</sl  otx/i  ni  targ> 

</initargs> 

</wrapper> 

</wrappers> 

<requi rements> 

<requi rement> 

<resource-class  count="2">MH-60</resource-class> 

</requi rement> 

</requi rements> 

<time-bounds-constrai  nts> 

<ref-hour  name="H"  type="start"> 

1035075079 

</ref-hour> 

<ref-hour  name="H"  type="fi ni sh"> 

1035123119 

</ref-hour> 

</time-bounds-constrai  nts> 

<duration> 

<i  ntervalxseconds>48040</secondsx/i  nterval> 

</duration> 

</acti vi ty> 

</i nstance> 


Figure  53:  XML  specifications  for  select  Exoti  c-Dancer  activity  instances 
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<type> 

<aircraft  name=MAC-130HM> 

<descri ption> 

Gunship:  close  air  support,  air 
interdiction,  and  force  protection 
</descri ption> 

<model -type>FIXED-WING</model -type> 
<speed  uni ts=MmphM>374</speed> 
<configurations> 

configuration  name=" :defaul t"> 
cargo  max=M10M>MUNITI0NS</cargo> 
</confi guration> 

</conf i gu  rati ons> 

</ai rcraft> 

</type> 


<type> 

<seacraft  name="CRRCM> 

<description> 

Combat  Rubber  Raiding  Craft: 
light  SOF  insertion/ exfiltration 
</description> 

<model -type>POWERED</model -type> 
<speed  uni ts=Mmph">10</speed> 
<configurations> 

configuration  name=" :default"> 
cargo  max="8M>PAX</cargo> 
</configuration> 

</conf i gu  rati ons> 

</seacraft> 

</type> 


<type> 

<ai re raft  name=MAH-64"> 

<descri ption> 

Apache:  attack  hel i copter 
</descri ption> 

<model -type>FIXED-WING</model -type> 
<speed  uni ts="mphM>374</speed> 
<configurations> 

configuration  name=" :defaul t"> 
cargo  max=M5M>MUNITI0NS</cargo> 
</confi guration> 

</conf i gu  rati ons> 

</ai rcraft> 

</type> 

<type> 

<aircraft  name=MC-17M> 

<descri ption> 

Globemaster  III:  cargo  and 
troop  transport 
</descri ption> 

<model -type>FIXED-WING</model -type> 
<speed  uni ts="mph">500</speed> 
<configurations> 

configuration  name="  :defaul  t"> 
cargo  max=M200M>PAX</cargo> 
</confi guration> 

</conf i gu  rati ons> 

</ai rcraft> 

</type> 


<type> 

<seacraft  name=MMK-VM> 

<description> 

Special  Operations  Craft: 
cargo  and  SOF  support 
</descri pti on> 

<model -type>POWERED</model  -type> 
<speed  units="mphM>70</speed> 
<conf i gu  rati ons> 

configuration  name=" :default"> 
cargo  max="20M>PAX</cargo> 
</conf i gu  rati on> 

</conf i gu  rati ons> 

</seacraft> 

</type> 

<type> 

<1 andcraft  name="HMMWVM> 
<description> 

Hi gh-Mobi 1 i ty  Multipurpose 
Vehicle:  light  tactical  vehicle 
</descri pti on> 

<model -type>WHEELED</model -type> 
<speed  uni ts=Mmph">10</speed> 
<conf i gu  rati ons> 

configuration  name=" :defaultM> 
cargo  max="8M>PAX</cargo> 
</conf i gu  rati on> 

</conf i gu  rati ons> 

</landcraft> 

</type> 


top(l-r): 

AC-130H 

AH-64 

C-17 


bottom: 

CRRC 

MK-V 

HMMWV 


Figure  54:  XML  specifications  of  Exoti  c-Dancer  resource  types 
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5.3.4  Resource  Instances 


All  of  the  place  instances  in  Exotic  Dancer  exist  solely  to  serve  as  named  locations  in  the  plan 
(i.e.,  for  calculating  travel  distances),  which  is  to  say,  there  are  no  accompanying  component 
resources  (like  worki  ng-MOG).  The  mobile  resources  are  also  apportioned  in  such  a  way  as  to 
facilitate  a  feasible  solution.  For  completeness’  sake,  a  description  of  the  Exotic  Dancer  resource 
instances  is  included  in  Table  10. 

Table  10:  Exotic-Dancer  resource  instances 


Resource 

Type 

Number  of 
Instances 

Initial  Location 

Aircraft 

AC-130H 

1 

Tampa  (TPA) 

2 

FSB  Black 

AH-64 

4 

FSB  Black 

C-17 

4 

Tampa  (TPA) 

MH-47 

5 

FSB  Black 

MH-60 

3 

FSB  Black 

Seacraft 

CRRC 

2 

Rendezvous  Location 

MK-V 

2 

AFSB  White 

Landcraft 

HMMWV 

4 

Objective  Landing  Zone 

Organic 

Infantry 

20 

Tampa  (TPA) 

FOOT 

DO 

n/a 
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definition  of  multiple  configurations  for  a  resource,  an  extension  that  would  allow  it  to  instan¬ 
tiate  derivative  setup  operations  to  perform  necessary  configuration  changes  (with  situation- 
specific  processing  durations)  would  require  very  little  in  the  way  of  additional  mechanisms  and 
make  Comirem  more  widely  applicable  to  manufacturing- 1  ike  problem  domains. 

6.1 .7  Abstract  Resource  Allocation 

Assignment  of  resources  ought  to  be  possible  at  any  level  in  the  Comirem  resource-requirement 
hierarchy  (see  Figure  16,  Section  3. 2. 2.1  (The  Resource  Requirement  Hierarchy),  page  29).  For 
example,  it  should  be  possible  to  commit  to  a  ROTOR  aircraft  for  a  given  activity  and  later  refine 
this  choice  to  a  specific  helicopter  type  (i.e.,  MH-60).  The  system  should  also  be  capable  of  rea¬ 
soning  with  these  abstract  partial  assignments.  That  is,  if  a  (partial)  assignment  is  made  at  the 
level  of  a  basic  air  capability  (e.g.,  an  ISR  asset)  and  there  are  no  ISR  assets  available  over  the 
period  of  time  during  which  it  is  needed,  then  the  system  should  recognize  this  problem.  Prop¬ 
agation  of  resource  constraints  in  this  example  must  be  capable  of  isolating  the  set  of  instances 
that  could  provide  this  capability  and  confirming  availability  of  at  least  one  instance.  More  gen¬ 
erally,  the  system  should  be  capable  of  maintaining  and  reasoning  with  a  plan/schedule  that 
contains  resource  assignments  or  partial  assignments  at  different  levels  of  specificity.  Going  one 
step  further,  it  should  be  possible  for  the  system  to  recognize  situations  where  user  decisions 
have  sufficiently  constrained  remaining  choices  such  that  only  one  unique  alternative  exists  at 
some  level.  In  these  cases  the  system  should  proceed  to  make  this  unique  assignment— which 
could  still  be  a  partial  one,  and  which  the  interface  should  make  clear  is  a  derived  choice. 

6.2  Scheduling  Issues 

A  great  opportunity  exists  in  Comirem  for  enhancing  the  scheduling  engine  by  opening  it  up 
to  accepting  additional  input  from  the  user.  We  are  interested  generally  in  the  design  of  user- 
directed  strategies  for  flexible-times  scheduling,  including  allowing  the  user  to  specify  relaxable 
constraints  and  objective  criteria  to  drive  the  scheduler.  Users  ought  to  be  able  to  specify  pref¬ 
erences  for  the  tightness  of  various  constraints  during  the  scheduling  process,  and  dictate  high- 
level  goals  for  the  overall  schedule  (or  perhaps  just  portions  of  the  schedule),  such  as  lowest 
risk,  lowest  cost  or  shortest  makespan. 

We  are  also  currently  in  the  process  of  investigating  extensions  to  facilitate  explicit  goal- 
directed  reasoning  about  the  resource-support  plans  required  to  enable  various  resource  as¬ 
signments  (see  [Smith  and  Zimmerman,  2004]). 

6.3  Planning  Issues 

A  major  area  of  continuing  interest  for  Comirem  is  the  enhancement  of  its  planning  capabilities. 
We  envision  providing  direct  interactive  support  for  creating  and  manipulating  activities  and 
activity  networks  through  the  GUI  to  extend  Comirem’s  forms-based  mixed-initiative  approach 
further  into  the  realm  of  planning. 

Users  ought  to  be  able  to  create  activity  networks  (perhaps  in  a  fashion  similar  to  that  of 
SOFTools/SOFPlan)  and  augment/modify  existing  networks  using  active-forms-style  GUI  tem¬ 
plates.  Moves  can  be  defined  by  establishing  temporal  links  (i.e.,  using  a  drag-and-drop  opera- 
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<requi rements> 

<requi  rementxresource-cl  ass>  R-|  </resource-cl  assx/requi  rement> 

<requi  rementxresource-cl  ass>  R2  </resource-cl  assx/ requi  rement> 

<requi  rementxresource-cl ass>  R3  </ resource-cl assx/ requi  rement> 

</ requi rements> 

the  assumption  of  the  scheduler  is  that  an  instance  of  each  of  resource  class  R-| ,  R2  and  R3 
must  be  reserved  for  the  duration  of  the  activity.  One  obvious  extension  to  this  format  would 
be  to  add  a  logical  operator  attribute  to  the  <requi  rements>  tag  that  would  indicate  how 
the  constituent  requirements  are  to  be  interpreted  (i.e.,  using  either  an  and  or  or).  In  the  case 
of  an  or  operator,  as  in  <requi  rements  operator="or">. .  ,</requi  rements>,  the  scheduler 
would  need  only  reserve  an  instance  of  one  of  the  R«  to  satisfy  the  needs  of  the  activity.  Further 
extensions  could  be  made  to  support  an  even  richer  resource-requirement  logic,  using  nested 
combinations  of  and  and  or  operators.24 

6.1.4  Consumable  Resources 

Consumable  commodities  (e.g.,  fuel,  munitions,  money)  are  not  currently  supported  by  Comi- 
rem.  The  work  ofLaborie  (see  above)  again  offers  useful  techniques  for  representing  and  man¬ 
aging  consumable  resources  that  could  be  used  to  extend  the  Comirem  resource  model. 

6.1.5  Producer  and  Consumer  Relations 

An  additional  class  of  resource- usage  constraints  not  yet  handled  by  Comirem  is  the  producer- 
consumer  relation.  For  example,  in  transshipment  contexts,  where  cargos  are  being  moved  to 
intermediate  locations  and  then  reconstituted  for  subsequent  movement  elsewhere,  the  relative 
carrying  capacities  of  the  resources  involved  at  each  stage  may  allow  execution  of  respective 
activities  to  be  overlapped,  thereby  reducing  the  overall  movement  duration.  By  adding  some 
additional  constraints  to  govern  the  repackaging  of  cargo,  the  sequencing  of  multiple-wave 
activities  can  be  controlled  at  a  much  finer  level  of  detail. 

Producer  and  consumer  relations  can  also  play  an  important  role  in  more  heavily  planning- 
related  situations,  like  those  involving  the  development  of  a  product,  as  in  an  ISR,  manufactur¬ 
ing  or  workflow  environment.  Sequencing  constraints  defined  as  producer-consumer  links  allow 
a  system  to  respond  to  execution  results  with  greater  flexibility.  For  example,  when  a  product 
does  not  meet  specifications,  the  system  may  be  able  to  iteratively  modify  and/or  reschedule  the 
original  production  steps  or  seek  other  avenues  for  securing  satisfactory  product. 

6.1.6  Situation-dependent  Setup  Operations 

The  concept  of  situation-dependent  resource  setup  operations  is  a  short  logical  step  from  that 
of  derivative  (de)positioning  legs  for  mobile  resources.  Given  that  Comirem  already  supports  the 

24lt  should  be  reiterated  that  the  model-type  in  the  resource-requirement  hierarchy  already  provides  a  degree  of 
or  functionality  by  allowing  multiple  resource  classes  to  be  grouped  together  into  a  single  class.  For  example,  a 
reference  to  the  ROTOR  model-type  in  a  resource  requirement  permits  Comirem  to  allocate  either  an  MH-47  orMH-60 
helicopter  to  an  activity. 
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definition  of  multiple  configurations  for  a  resource,  an  extension  that  would  allow  it  to  instan¬ 
tiate  derivative  setup  operations  to  perform  necessary  configuration  changes  (with  situation- 
specific  processing  durations)  would  require  very  little  in  the  way  of  additional  mechanisms  and 
make  Comirem  more  widely  applicable  to  manufacturing- 1  ike  problem  domains. 

6.1 .7  Abstract  Resource  Allocation 

Assignment  of  resources  ought  to  be  possible  at  any  level  in  the  Comirem  resource-requirement 
hierarchy  (see  Figure  16,  Section  3. 2. 2.1  (The  Resource  Requirement  Hierarchy),  page  29).  For 
example,  it  should  be  possible  to  commit  to  a  ROTOR  aircraft  for  a  given  activity  and  later  refine 
this  choice  to  a  specific  helicopter  type  (i.e.,  MH-60).  The  system  should  also  be  capable  of  rea¬ 
soning  with  these  abstract  partial  assignments.  That  is,  if  a  (partial)  assignment  is  made  at  the 
level  of  a  basic  air  capability  (e.g.,  an  ISR  asset)  and  there  are  no  ISR  assets  available  over  the 
period  of  time  during  which  it  is  needed,  then  the  system  should  recognize  this  problem.  Prop¬ 
agation  of  resource  constraints  in  this  example  must  be  capable  of  isolating  the  set  of  instances 
that  could  provide  this  capability  and  confirming  availability  of  at  least  one  instance.  More  gen¬ 
erally,  the  system  should  be  capable  of  maintaining  and  reasoning  with  a  plan/schedule  that 
contains  resource  assignments  or  partial  assignments  at  different  levels  of  specificity.  Going  one 
step  further,  it  should  be  possible  for  the  system  to  recognize  situations  where  user  decisions 
have  sufficiently  constrained  remaining  choices  such  that  only  one  unique  alternative  exists  at 
some  level.  In  these  cases  the  system  should  proceed  to  make  this  unique  assignment— which 
could  still  be  a  partial  one,  and  which  the  interface  should  make  clear  is  a  derived  choice. 

6.2  Scheduling  Issues 

A  great  opportunity  exists  in  Comirem  for  enhancing  the  scheduling  engine  by  opening  it  up 
to  accepting  additional  input  from  the  user.  We  are  interested  generally  in  the  design  of  user- 
directed  strategies  for  flexible-times  scheduling,  including  allowing  the  user  to  specify  relaxable 
constraints  and  objective  criteria  to  drive  the  scheduler.  Users  ought  to  be  able  to  specify  pref¬ 
erences  for  the  tightness  of  various  constraints  during  the  scheduling  process,  and  dictate  high- 
level  goals  for  the  overall  schedule  (or  perhaps  just  portions  of  the  schedule),  such  as  lowest 
risk,  lowest  cost  or  shortest  makespan. 

We  are  also  currently  in  the  process  of  investigating  extensions  to  facilitate  explicit  goal- 
directed  reasoning  about  the  resource-support  plans  required  to  enable  various  resource  as¬ 
signments  (see  [Smith  and  Zimmerman,  2004]). 

6.3  Planning  Issues 

A  major  area  of  continuing  interest  for  Comirem  is  the  enhancement  of  its  planning  capabilities. 
We  envision  providing  direct  interactive  support  for  creating  and  manipulating  activities  and 
activity  networks  through  the  GUI  to  extend  Comirem’s  forms-based  mixed-initiative  approach 
further  into  the  realm  of  planning. 

Users  ought  to  be  able  to  create  activity  networks  (perhaps  in  a  fashion  similar  to  that  of 
SOFTools/SOFPlan)  and  augment/modify  existing  networks  using  active-forms-style  GUI  tem¬ 
plates.  Moves  can  be  defined  by  establishing  temporal  links  (i.e.,  using  a  drag-and-drop  opera- 
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tion)  between  two  locations;  events  can  be  defined  similarly  by  specifying  a  temporal  interval  at 
a  single  location.  Sequencing  constraints,  similar  to  moves,  are  temporal  links  (perhaps  anno¬ 
tated)  between  activities.  Finally,  the  XML  specification  for  an  activity  type  ought  to  be  derivable 
directly  from  existing  instantiations,  for  future  use  in  other  plans. 

6.4  Architectural  Issues 

Comirem’s  lightweight  client/server  design  provides  the  basis  for  a  number  of  possible  exten¬ 
sions  towards  supporting  a  fully  multi-user  planning  and  scheduling  environment.  As  shown  in 
Figure  55,  a  single  Comirem  server  could  manage  one  or  more  planning/scheduling  scenarios 
for  multiple  clients,  with  access  controlled  through  locking  and/or  other  mechanisms.  Issues 
related  to  the  synchronization  of  multiple  modifications  to  the  same  scenario  would  need  to 
be  addressed  formally  or  prevented  outright.  Additionally,  the  client/server  design  provides  the 
means  for  supporting  message  passing  between  clients  (e.g.,  users  working  on  related  scenarios 
or  different  parts  of  the  same  scenario)  and  even  the  dynamic  modular  configuration  of  plan¬ 
ning/scheduling  clients,  where  users  would  be  able  to  tailor  their  own  client  environment  based 
on  their  individual  needs  or  context  and  thereby  minimize  even  further  the  total  footprint  of 
their  application  and  its  impact  on  the  server. 


Clients 


Internet/LAN  Connection 


Server  Messages: 

•  scheduling  results 
•schedule  changes 


Client  Messages: 

•  scheduling  requests 
•scheduling  queries 


Comirem  Scheduler  Server 


Figure  55:  Comirem  multi-user  client/server  environment 
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A  Input  Data  Specifications 

This  appendix  provides  the  complete  XML  specification  grammar  for  each  of  the  data  elements 
that  can  appear  in  a  Comirem  input  data  file.  It  is  organized  into  five  sections,  covering  basic 
support  entities  (including  constraints),  activities  (types  and  instances),  resources  (types  and 
instances),  capabilities,  and  plan  configurations. 

Figure  56  displays  an  XML-centered  layout  of  the  input  data  files  that  comprise  a  situation 
(i.e.,  the  types,  capabilities  and  instances  files  on  the  left)  and  scenario  (i.e.,  the  plan 
file  on  the  right)  in  Comirem,  as  introduced  in  Figure  1,  Section  3.1  (Representation  of  SO F 
Domains),  page  8. 

situation- types .  xml 


<typeFi 1 e> 

resource  types 
</typeFi 1 e> 


situation-capabi  1  i  ti  es .  xml 


<capabilityFile> 

capability  instances 
</ capabi 1 i tyFi 1 e> 


situation -i  nstances .  xml 


<i  nstanceFi 1 e> 

resource  instances 
situation-specific  place  instances 
</i nstanceFi  1  e> 


scenario- pi  an .  xml 


<pl  anFi  1  e  name=  " scenario-name ”  > 
plan-configuration 
<instances> 

scenario-specific  place  instances 
activity  instances 
constraint  instances 
</instances> 

</pl anFi  1  e> 


Figure  56:  Comirem  input  file  format  description 


A.1  Supporting  Entities 

The  supporting  entities  described  in  this  section  facilitate  the  specification  of  temporal,  ge¬ 
ographic,  cargo  and  constraint  information.  These  entities  are  referenced  by  multiple  other 
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Comirem  data  entities  in  the  process  of  representing  an  input  situation  or  scenario. 

A.1.1  Time  Formats 

The  time  formats  in  this  section  match  those  described  in  Active  Templates  program  document 
number  1 :  Representing  Temporal  Data  in  the  Structured  Data  Model  (see  [Lafferty,  2001  b]). 

The  basic  temporal  specifications  in  Comirem  cover  both  absolute  times  and  time  intervals. 
Absolute  times  are  used  for  specifying  release  and  due  dates  and  constraining  activity  start  and 
end  times.  Time  intervals  are  used  in  the  specification  of  upper  and  lower  temporal  bounds 
on  both  constraints  and  durations.  A  specific  duration  entity  is  provided  for  specifying  mini¬ 
mum/maximum  ranges  and  fixed  time  points  for  activity  durations. 

A.1.1.1  Absolute  Time 

Absolute  time  in  Comirem  can  be  specified  as  a  calendar  date  with  an  optional  clock  time  (to 
thousandths  of  a  second),  either  in  Zulu  time  or  offset  from  Zulu  time  by  some  number  of  hours 
and/or  minutes.  The  time  specification  format  is  presented  in  Table  11 . 

Table  11 :  Time  specification  format 


Grammar  for  time-spec 

time-spec 

CCYYMMDD  ‘V  hhmmss  [V 

’sss  ]  [  (  zulu-suffix  |  offset-suffix  )  ] 

CC 

the  century  component  of  a  year;  range:  [00,99] 

YY 

the  tens  and  units  components  of  a  year;  range:  [00,99] 

MM 

a  month;  range:  [01,12] 

28  :  MM  =  02  A  CCYY  leap  year 

DD 

a  day;  range:  [01 ,  < 

29  :  MM  =  02  A  CCYY  =  leap  year 
30:  MM  C  {04,06,09,11} 

>] 

31  :  MM  C  {01,03,05,07,08,10,12}  ^ 

hh 

an  hour;  range:  [00,23] 

mm 

minutes;  range:  [00,59] 

ss 

seconds;  range:  [00,59] 

sss 

thousandths  of  a  second;  range:  [000,999] 

zulu-suffix 

‘Z’ 

Designates  Zulu  time  (the  default  is 

local) 

offset-suffix 

C+’| 

c— ?)  hhmm 

Designates  an  offset  from  Zulu  time 
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A.1.1.2  Intervals 


Time  intervals  are  blocks  of  time  specified  in  terms  of  standard  time  units  (e.g.,  seconds,  min¬ 
utes,  hours),  as  well  as  the  system-defined  values:  : infinity  (i.e.,  an  unbounded  positive 
amount  of  time)  and  : negative-infinity  (i.e.,  an  unbounded  negative  amount  of  time).25 
The  interval  specification  format  is  presented  in  Table  12. 


Table  12:  Interval  specification  format 


Grammar  for  interval-spec 


interval-spec 


time-spec 


interval-string 

hms-suffix 


<i  nterval> 

time-spec  |  : negative-infinity  |  : infinity 
|  (  <i nterval -stri ng>  interval-string  </i nterval -stri ng>  ) 
</interval> 

[<seconds>  integer  </ seconds>]  [<mi nutes>  integer  </mi nutes>] 
[<hours>  integer </hours>]  [<days>  integer </days>] 

[<weeks> integer  </weeks>]  [<months>  integer </months>] 
[<years>  integer  </years>] 

[‘— ’]  ‘P’  [integer ‘Y’]  [integer‘M’]  [integer‘D’]  [  hms-suffix  ] 

T’  [integer'IT]  [integer ‘M’]  [(  integer  |  float) ‘S’] 


A.1.1.3  Duration 

Durations  in  Comirem  can  be  specified  as  either  fixed  amounts  of  time  or  lower  and/or  upper- 
bounded  time  ranges  (i.e.,  using  the  interval-spec  time-interval  format).  The  duration  specifica¬ 
tion  format  is  presented  in  Table  13. 

A.1.2  Geographical  Formats 

The  formats  in  this  section  handle  such  geographical  entities  as  locations,  distances  and  speeds. 

A.1.2.1  Locations 

The  location  formats  in  this  section  correspond  to  those  described  in  Active  Templates  program 
document  number  2:  Representing  Geographic  Data  in  the  Structured  Data  Model  ([Lafferty,  2001  a]). 

Locations  are  represented  by  latitude/longitude  pairs  with  an  optional  altitude  value.  In 
the  absence  of  an  altitude  specification,  a  location  is  assumed  to  be  at  sea  level.  Latitude  and 
longitude  values  are  specified  in  degrees  as  floats  using  a  [-]DDD.ddd  format,  with  negative 

25Note  that  the  only  way  (currently)  to  specify  a  negative  bounded  time  is  to  use  the  i  nterval  -stri  ng  tag. 
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Table  13:  Duration  specification  format 


Grammar  for  duration-spec 

Notes 

duration-spec 

— >  <duration> 

(  [min-spec]  [ max-spec ]  )  |  fixed-spec 
</duration> 

min-spec 

— >  <minimum>  interval-spec  </minimum> 

a 

max-spec 

— >  <maximum>  interval-spec  </maximum> 

a 

fixed-spec 

— >  <fixed>  interval-spec  </fixed> 

a 

a:  for  interval-spec  grammar,  see  Table  12,  page  91 


values  implying  the  southern  hemisphere  for  latitude  and  the  eastern  hemisphere  for  longitude. 
Altitudes  can  be  specified  in  a  variety  of  distance  units.  The  location  specification  format  is 
presented  in  Table  14. 


Table  14:  Location  specification  format 


Grammar  for  location-spec 

Notes 

location -spec  — >  <location  latitude-spec  longitude-spec> 

[altitude-spec] 

</location> 

latitude-spec  longitude=“FLOAT” 

longitude-spec  — >  latitude=“FLOAT” 

altitude-spec  — >  <altitude>  distance-spec  </altitude> 

a 

a:  for  distance-spec  grammar,  see  Table  15,  page  93 


A.1.2.2  Distance 

Distances  can  be  specified  as  integers  or  floats  in  units  offeet,  meters,  yards,  kilometers  or  miles. 
The  distance  specification  format  is  presented  in  Table  15. 
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Table  15:  Distance  specification  format 


G  ram  m  ar  fo  r  distance-spec 


distance-spec  —¥  <di stance  u n i  t s = “distance-units ”  > 

INTEGER  I  FLOAT 

</di stance> 

distance-units  — >  feet  |  meters  |  yards  |  kilometers  |  miles 


A.1.2.3  Speed 

Speeds  can  be  specified  as  integers  or  floats  in  units  of  feet-per-second  (fps),  miles-per-hour 
(mph),  or  knots.  The  speed  specification  format  is  presented  in  Table  16. 

Table  16:  Speed  specification  format 
G  ram  m  ar  fo  r  speed -spec 

speed-spec  — >  <speed  units =  uspeed-units”>  integer  </speed> 
speed-units  — >  fps  |  mph  |  knots 


A.1.3  Cargo  Format 

The  cargo  format  serves  two  purposes:  it  supports  the  specification  of  units  of  cargo  comprising 
the  manifest  for  an  activity,  and  an  upper  bound  on  resource  capacity  when  defining  a  resource 
configuration.  The  former  case  makes  use  of  a  count  XML  attribute,  while  the  latter  uses  a  max 
attribute.  Comirem  provides  a  predefined  set  of  generic  cargo  types:  PAX  (for  personnel),  FUEL, 
MUNITIONS,  PALLETS  and  AIRCRAFT.  The  cargo  specification  format  is  presented  in  Table  17. 

A.1.4  Constraint  Formats 

Comirem  constraint  formats  cover  both  temporal  sequencing  and  reference  hour  constraints. 

A.1 .4.1  Temporal  Sequencing  Constraints 

Temporal  sequencing  constraints  are  used  to  specify  temporal  relations  among  activities  within 
a  plan  and  among  subactivities  (i.e.,  children)  of  an  aggregate  activity.  Each  constraint  must 
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Table  17:  Cargo  specification  format 


G  ram  m  ar  fo  r  cargo-spec 

cargo-spec 

<car go  [count-spec]  [max-spec]  >  cargo-type  </cargo> 

count-spec 

count=  “integer” 

max-spec 

max=  “integer” 

cargo-type 

PAX  |  FUEL  |  MUNITIONS  |  PALLETS  |  AIRCRAFT 

specify  a  set  of  nodes  both  from  which  the  constraint  relation  emanates  and  to  which  it  leads. 
When  the  constraint  specifies  a  relation  between  subactivities,  the  from-type  and  to-type  variants 
may  be  used,  to  take  advantage  of  the  fact  that  subactivities  need  not  be  named,  and  can 
therefore  be  accessed  by  their  type  alone— assuming  that  the  type  is  unique  among  all  of  the 
(local)  subactivities.  Also  in  this  case,  the  special  keyword,  :  chi  Id,  can  be  used  to  refer  to  a 
nexus  activity  from  within  a  wrapper,  since  its  name  cannot  be  determined  until  instantiation 
time. 

The  predefined  temporal  constraint  types,  as  defined  in  Section  3. 2. 3.1  (Temporal  Sequenc¬ 
ing  Constraints),  are:  successor/before,  same-start  and  same-finish,  overlaps  and  con- 
tai  ns.  The  temporal  constraint  specification  format  is  presented  in  Table  18. 

A.1.4.2  Reference  Hour  Constraints 

Reference  hour  constraints  are  specified  at  the  plan  level  and  used  to  implement  Comirem’s  ref- 
hours.  They  attach  a  name,  say  P,  to  a  particular  point  in  time  fixed  to  Comirem’s  underlying 
constraint  network’s  calendar  zero,  and  may  include  an  optional  delta  value  that  specifies  a  time 
window  centered  around  P,  i.e.,  [P— A,P+A],  from  which  any  time  point  linked  to  the  ref-hour 
can  be  offset,  using  an  additional  value.  The  values  of  P,  A  and  the  offset  can  be  changed  at 
any  time.  If  either  of  these  values  is  modified,  each  of  the  time  points  linked  to  the  ref-hour 
must  be  updated  in  response.  The  reference  hour  constraint  specification  format  is  presented 
in  Table  19. 

A.2  Activity  Attributes 

The  various  specification  formats  for  activity  attributes  are  presented  in  this  section.  Note 
that  the  distinction  between  type  and  instance  attributes  is  not  strictly  defined  (or  enforced) 
in  Comirem.  That  is  to  say,  it  is  generally  permissible  to  specify  any  attribute  at  either  the  type 
or  instance  level.  Attributes  specified  at  the  type  level  will  apply  to  all  instances  of  the  type, 
and  attributes  specified  at  the  instance  level  will  override  type-level  definitions.  In  this  section, 
attributes  have  been  grouped  according  to  how  they  are  typically  specified  in  Comirem  data 
files. 
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Table  18:  Temporal  sequencing  constraint  specification  format 


Grammar  for  constraint-spec 

Notes 

constraint-spec  — > 

<constrai nt> 

type-ref-spec  from-spec  to-spec  [lb-spec]  [ub-spec] 

</constrai nt> 

type-ref-spec  — > 

<type-ref>  constraint-type-name  </type-ref> 

constraint-type-name  — > 

successor  |  before  |  same-start 

same-finish  overlaps  contains 

from-spec  — > 

<from>  [  :  chi  Id  activity-name  ]+  </from> 

a 

<f  rom-type>  [  child-type-name  ]+  </f  rom-type> 

t 

b 

to-spec  — > 

<to>  [  :  chi  Id  activity-name  ]+  </to> 

a 

<to-type>  [  child-type-name  ]+  </to-type> 

t 

b 

lb-spec  — > 

<1  b>  interval-spec  </l  b> 

c 

u  b-spec  — > 

<ub>  interval-spec  </ub> 

c 

f:  this  tag  is  not  relevant  for  plan-level  constraints,  i.e.,  in  the  scenario-plan . 

xml  file 

a:  activity-name  must  uniquely  match  a  current  activity  instance  (the  match  must  be 
with  a  child  activity  specified  in  an  accompanying  decomposi  tion  tag  if  the  con¬ 
straint  defines  an  inter-activity  relation) 

b:  child-type-name  must  uniquely  match  a  child  activity  type  as  specified  in  an  accom¬ 
panying  decomposi ti  on  tag 
c:  for  interval-spec  grammar,  see  Table  12,  page  91 


As  should  be  expected,  activity  type  and  instance  names  must  be  unique  within  a  scenario. 
The  activity  type  specification  format  is  presented  in  Table  20,  and  the  activity  instance  specifi¬ 
cation  format  is  presented  in  Table  21 . 
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Table  19:  Reference  hour  constraint  specification  format 


Grammar  for  ref-hours-spec 

Notes 

ref-hours-spec  — >  <ref-hours>  [re/r-/?owr-spec]+  </ref-hours> 

ref-hour-spec  — )•  <ref-hour  r\ame=“ref-hour-name”  > 

<time>  ( time-spec  |  integer  )  </time> 

a 

<delta>  interval-spec  </delta> 

b 

</ ref-hour> 

a:  for  time-spec  grammar,  see  Table  11,  page  90 
b:  for  interval-spec  grammar,  see  Table  12,  page  91 
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Table  20:  Activity  type  specification  format 


Gram  m  ar  for  activity-type-spec 

Notes 

activity-type-spec  — ¥  <type> 

<activity-type-name  name=  “new-type-name”  > 

[description-spec] 

[variables-spec] 

[inputs-spec] 

[decomposition-spec] 

a 

[constraints-spec] 

b 

[wrappers-spec] 

c 

[requirements-spec] 

d 

[<deri vati ve-p/>] 

[capability-type-spec] 

</ activity-type-name> 

</type> 

activity-type-name  — >  wrapper  |  move  |  event 

description-spec  — >  <description>  text  </description> 

variables-spec  — >  <variables>  [symbol]+  </variables> 

inputs-spec  — >  <inputs>  [symbol]+  </inputs> 

capability-type-spec  — >  <capabi  1  i  ty-type>  ( move  event )  </ capabi  1  i  ty-type> 

a:  for  decomposition-spec  grammar,  see  Table  22,  page  99 
b:  for  constraints-spec grammar,  see  Table  23,  page  100 
c:  for  wrappers-spec  grammar,  see  Table  24,  page  100 
d:  for  requirements-spec  grammar,  see  Table  26,  page  102 


97 


Table  21 :  Activity  instance  specification  format 


activity-instance-spec 


type-ref-spec 

display-name-spec 

origin-spec 

destination-spec 


place-spec 

time-constraints-spec 


ref-hour-con-spec 


time-point 

anchor-con-spec 


time-constraint-type 


Grammar  for  activity-instance-spec 


Notes 


<i nstance> 

<acti  vi  ty  nam e=“activity-name”  > 

type-ref-spec  [display-name-spec]  [time-constraints-spec] 


</activity> 

</i nstance> 

<type-ref>  type-name  </type-ref> 
<display-name>  text  </display-name> 

<origin>  ( place-name  |  location-spec )  </origin> 
<destination> 

(  place-name  |  location-spec  ) 

</destination> 

<place>  ( place-name  \  location-spec)  </place> 
<time-bounds-constrai  nts> 

[  ref-hour-con-spec  \  anchor-con-spec  ]+ 
</time-bounds-constrai nts> 

<ref-hour  r\ame=“ref-hour-name”  type=  “time-point”  > 
(  time-spec  |  integer  ) 

</ ref-hour> 

(  start  |  fi ni sh  ) 

<anchor  type=  “time-constraint-type” > 

(  time-spec  |  integer  ) 

</anchor> 


a,  b,  c 

d 

e,  f 
e,  f 
e,  f 


g 

h 


h 


EST  LST  EFT  LFT 


f :  this  option  is  only  relevant  for  move  activity  types 
J:  this  option  is  only  relevant  for  event  activity  types 


a:  for  initargs-spec  grammar,  see  Table  25,  page  101 
b:  for  manifest-spec  grammar,  see  Table  27,  page  103 
c:  for  duration-spec  grammar,  see  Table  13,  page  92 
d:  type-name  must  refer  to  a  predefined  activity  type 
e:  place-name  must  refer  to  a  defined  place  resource  instance 
f:  for  location-spec  grammar,  see  Table  14,  page  92 
g:  ref-hour-name  must  refer  to  a  predefined  ref-hour 
h:  for  time-spec  grammar,  see  Table  11 ,  page  90 
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A.2.1  Aggregate  Decomposition 

The  aggregate  decomposition  specification  is  typically  defined  at  the  type  level,  to  indicate  how 
an  aggregate  activity  (possibly  a  wrapper),  decomposes  into  subactivities.  Initargs  are  also 
passed  to  subactivities  using  this  tag.  It  is  only  necessary  to  pass  initargs  for  instance  slots 
that  are  relevant  to  the  recipient.  Note  also,  though,  that  if  an  initarg  for  an  instance  slot  is 
not  passed,  its  value  will  be  unbound,  indicating,  in  the  case  of  the  variables  maintained  by  an 
activity  (i.e.,  specified  using  the  <variab1es>  tag),  that  they  are  free.  For  example,  if  values 
for  the  resource-origin  and  resource-destination  variables  maintained  by  the  RESOURCE- 
SOURCING  wrapper  activity  are  not  specified  by  an  invoking  activity  instance,  then  a  resource 
allocated  to  this  activity  may  be  sourced  from  anywhere. 

The  aggregate  decomposition  specification  format  is  presented  in  Table  22. 


Table  22:  Aggregate  decomposition  specification  format 


Gram m ar  for  decomposition-spec 

Notes 

decomposition-spec  — >  <decomposition>  [child-spec]^  </decomposition> 

child-spec  — >  <chi  1  d-spec  [nam e=“child-name”  ]> 

type-ref-spec 

[initargs-spec] 

a 

</child-spec> 

type-ref-spec  — >  <type-ref>  child-type-name  </type-ref> 

b 

a:  for  initargs-spec  grammar,  see  Table  25,  page  101 
b:  child-type-name  must  refer  to  a  predefined  activity  type 


A.2.2  Aggregate  Constraints 

The  aggregate  constraint  specification,  also  typically  defined  at  the  type  level,  establishes  the  se¬ 
quential  relationships  among  the  subactivities  of  an  aggregate  activity  (again,  possibly  a  wrap¬ 
per),  using  the  temporal  sequencing  constraints  described  in  Section  A. 1.4.1  (Temporal  Se¬ 
quencing  Constraints).  The  aggregate  constraint  specification  format  is  presented  in  Table  23. 


A.2.3  Wrapper  Invocation 

The  wrapper  specification  is  typically  defined  at  the  type  level,  to  expand  an  activity  upward 
(i.e.,  into  superactivities).  Similarly  to  the  behavior  of  an  aggregate  decomposition,  initargs  are 
used  to  pass  slot  values  up  to  the  wrapper  activity  instance.  The  wrapper  specification  format 
is  presented  in  Table  24. 
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Table  23:  Aggregate  constraint  specification  format 


Gram  m  ar  for  constraints-spec 

Notes 

constraints-spec  — >  <constrai  nts>  [constraint-spec]^  </constrai  nts> 

a 

a:  for  constraint-spec  grammar,  see  Table  18,  page  95 


Table  24:  Wrapper  specification  format 


Gram  m  ar  for  wrappers-spec 

Notes 

wrappers-spec  — >  <wrappers>  [wrapper-spec]^  </wrappers> 

wrapper-spec  — »  <wrapper  name=  “wrapper-name” > 

a 

[initargs-spec] 

b 

</wrapper> 

a:  wrapper-name  must  refer  to  a  predefined  wrapper  type 
b:  for  initargs-spec  grammar,  see  Table  25,  page  101 


A.2.4  Initialization  Arguments 

As  has  already  been  mentioned,  initialization  arguments  (i.e.,  initargs),  are  used  to  pass  values 
from  one  activity  to  another,  whether  it  be  from  activity  to  subactivity  or  from  activity  to  super¬ 
activity.  Because  Comirem  is  built  on  the  Common  Lisp  Object  System  (CLOS)  [Keene,  1989], 
the  model  for  initargs  reflects  the  underlying  CLOS  object  model. 

Initarg  values  can  be  specified  in  one  of  three  ways: 


1.  the  value  of  a  slot  -  a  slot-name  is  identified,  and  the  value  passed  with  the  initarg  is  the 
value  of  that  slot  belonging  to  the  activity  that  is  passing  the  initarg 

2.  an  explicit  value  -  the  value  is  passed  with  the  initarg 

3.  a  keyword  name  -  a  keyword  is  identified,  and  the  value  passed  with  the  initarg  is  the  value 
that  was  paired  with  the  keyword  when  the  activity  that  is  passing  the  initarg  was  instan¬ 
tiated 


The  initarg-name  is  the  name  of  an  initarg  that  is  acceptable  to  the  activity  to  which  the  initarg 
is  being  passed.  The  initarg  specification  format  is  presented  in  Table  25. 
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Table  25:  Initialization  argument  specification  format 


Gram  m  ar  for  initargs-spec 

Notes 

initargs-spec  — >  <initargs>  [initarg-spec]+  </initargs> 

initarg-spec  >  <initarg  r\ame=initarg-name> 

a 

slot-spec  |  value-spec  \  keyword-spec 

</initarg> 

slot-spec  — >  <slot>  slot-name  </slot> 

b 

value-spec  — >  <val  ue>  value  </val  ue> 

c 

keyword-spec  — >  <keyword>  keyword  </keyword> 

d 

a:  initarg-name  must  be  an  initarg  for  the  targeted  activity  instance 
b:  slot-name  must  reference  either  a  slot,  variable  or  input  of  the  cur¬ 


rent  activity  instance 

c:  value  should  be  a  value  appropriate  for  initarg-name 

d:  keyword  must  be  a  keyword  provided  to  the  current  activity  instance 


A.2.5  Resource  Requirements 

Resource  requirements  can  be  specified  at  either  the  type  or  instance  level.  The  resource- 
requirement  specification  tells  the  scheduler  what  kinds  of  resources— and  how  many  of  each- 
must  be  secured  to  satisfy  an  activity.  The  specification  of  a  capability,  model  type  or  resource 
class  automatically  includes  all  of  the  selection’s  children  (and  their  children,  etc.)  as  candidate 
resources  with  which  to  satisfy  a  particular  requirement.  The  optional  count  attribute  allows 
the  planner  to  override  the  default  calculation,  performed  by  the  scheduler,  that  determines 
how  many  actual  resource  instances  are  required  by  an  activity  depending  on  the  nature  of  its 
cargo  manifest.  For  example,  a  resource  type  with  the  capability  to  handle  100  PALLETS,  se¬ 
lected  for  an  activity  that  has  a  cargo  manifest  of  400  PALLETS,  will  require  four  instances  of 
that  resource  type  to  be  allocated  to  the  activity. 

Currently  in  Comirem,  each  individual  resource  requirement  represents  a  requirement  that 
must  be  satisfied.  If  there  are  two  requirements  (R-|  and  R2),  then  a  resource  (or  resources) 
satisfying  R-|—  and— a  resource  (or  resources)  satisfying  R2  must  be  secured  (i.e.,  there  is  an 
implied  and  operator  among  multiple  requirements). 

Note  that  there  are  additional  semantics  involved  with  the  modification  of  resource  require¬ 
ments,  i.e.,  through  the  Comirem  GUI.  This  issue  is  discussed  in  Section  B.4.1.5. 

The  resource-requirement  specification  format  is  presented  in  Table  26. 

A.2.6  Cargo  Manifests 

Cargo  manifests  are  generally  specified  at  the  instance  level.  They  describe  a  quantity  of  cargo 
that  must  be  accommodated  by  an  activity’s  required  resource(s).  Absent  a  count  attribute  in 
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Table  26:  Resource  requirement  specification  format 


Grammar  for  requirements-spec 

Notes 

requirements-spec  — v  <requi  rements>  [requirement-spec]+  </requi  rements> 

requirement-spec  — f  <requi  rement  [  count=  “integer”  ]  > 

a 

capabilities-spec  |  resource-class-spec 

model-type-spec  \  resource-spec 

</ requi rement> 

capabilities-spec  — f  <capabilities>  [capability- name]+  </capabilities> 

b 

resource-class-spec  — f  <resource-class> 

[ resource-class-name ] + 

c 

</resource-cl ass> 

model-type-spec  — f  <model-type>  [model-type]+  </model -type> 

d 

resource-spec  — f  <resource>  resource-name  </resource> 

e 

a:  the  optional  count  attribute  overrides  the  calculation  that  determines  how  many  resource 


instances  are  required  fora  particular  activity 
b:  capability- name  names  a  capability  (if  it  does  not  yet  exist,  it  will  be  created) 
c:  resource-class-name  must  refer  to  a  predefined  resource  class 
d:  model-type  must  refer  to  a  predefined  model  type 

e:  resource-name  must  refer  to  an  existing  resource  instance  (this  is  not  currently  supported) 


an  activity’s  resource  requirement,  the  cargo  manifest  helps  drive  the  calculation  to  determine 
how  many  resource  instances  are  needed  to  perform  an  activity.  The  cargo  manifest  specifica¬ 
tion  format  is  presented  in  Table  27. 

A.3  Resource  Attributes 

The  various  specification  formats  for  resource  attributes  are  presented  in  this  section.  Note  that, 
as  in  the  case  of  activities,  the  distinction  between  type  and  instance  attributes  for  resources  is 
not  strictly  defined.  Again,  attributes  specified  at  the  type  level  will  apply  to  all  instances  of 
the  type,  and  attributes  specified  at  the  instance  level  will  override  type-level  definitions.  In  this 
section,  attributes  have  been  grouped  according  to  how  they  are  typically  specified  in  Comirem 
data  files. 

As  should  be  expected,  resource  type  and  instance  names  must  be  unique  within  a  scenario. 
The  resource  type  specification  format  is  presented  in  Table  28,  and  the  resource  instance  spec¬ 
ification  format  is  presented  in  Table  29.  In  the  specification  of  resource  instances,  note  that 
only  places  can  have  components  (capacitated  or  not),  and  that  places  can  only  be  placed  at 
a  location  specified  by  a  latitude/longitude  pair  (i.e.,  they  cannot  be  treated  as  components).26 

26Note  that  if  a  component  resource  is  referenced  in  a  components-spec,  it  must  also  be  defined  separately. 
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Table  27:  Cargo  manifest  specification  format 


Gram m ar  for  manifest-spec 

Notes 

manifest-spec  — >  <manifest>  [manifest-entry-spec]+  </manifest> 

manifest-entry-spec  <mani  fest-entry>  cargo-spec  </mani  fest-entry> 

a 

a:  for  cargo-spec  grammar,  see  Table  17,  page  94 


Table  28:  Resource  type  specification  format 


Gram  m  ar  for  resource-type-spec 

Notes 

resource-type-spec 

<type> 

<resource-type  name= “new-type-name”  > 

[model-type-spec] 

description-spec] 

[speed-spec] 

t 

a 

configurations-spec] 

[capabilities-spec] 

b 

</ resource-type> 
</type> 

resource-type 

aircraft  |  landcraft  seacraft 

mobile  place 

component 

model-type-spec 

<model 

-type>  model-type  </model  -type> 

c 

description-spec 

<description>  text  </description> 

capabilities-spec 

<capabilities>  [capabiiity-name]-\-  </capabilities> 

f:  these  options  are  only  relevant  for  mobile  resource  types 

a:  for  speed-spec  grammar,  see  Table  16,  page  93 

b:  for  configurations-spec  grammar,  see  Table  30,  page  105 

c:  model-type  must  refer  to  a  predefined  model  type 
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Table  29:  Resource  instance  specification  format 


resource-instance-spec 


resource-type 

type-ref-spec 

placement-spec 


Gram m ar  for  resource-instance-spec 


Notes 


<i nstance> 

<resource-type  n ame=  “resource-name”  > 


type-ref-spec 
placement-spec 


[j place-only-options ]  f 


capacity-list-spec ] 

</ resource-type> 

</i nstance> 

resource  |  place  |  component 
<type-ref>  type-name  </type-ref> 
<placement> 


location-spec  \  place-name 


b 

c,  d 


place-only-options 

components-spec 


[components-spec] 

<components> 


[i uncapacitated-components-spec ] 
[component-name]+  </components> 


e 


f :  this  option  is  only  relevant  for  pi  ace  instances 
J :  this  option  is  not  relevant  for  pi  ace  instances 


a:  for  capacity-list-spec  grammar,  see  Table  31,  page  106 

b:  type-name  must  refer  to  a  predefined  resource  type 

c:  for  location-spec  grammar,  see  Table  14,  page  92 

d:  place-name  should  refer  to  a  place  resource  instance 

e:  for  uncapacitated-components-spec  grammar,  see  Table  32,  page  107 


A.3.1  Configurations 

Configuration  specifications  define  the  capacity  of  a  resource  under  different  setups  (i.e.,  con¬ 
figurations),  and  are  typically  defined  at  the  type  level.  Each  configuration  option  fora  resource 
does  two  things:  (1)  it  links  the  resource  to  a  capability,  and  (2)  it  provides  the  information 
necessary  to  determine  its  ability  to  handle  a  particular  activity  based  on  the  activity’s  cargo 
manifest.  As  illustrated  in  Figure  10,  Section  3. 2. 1.3  (Sibling  Activities),  page  20,  and  absent  a 
count  attribute  appearing  in  an  activity’s  resource  requirement,  the  cargo  manifest  is  matched 
against  the  relevant  resource  configuration— designated  by  the  required  capability— to  determine 
how  many  instances  of  a  resource  are  necessary  to  perform  the  activity.  If  no  capability  is  spec¬ 
ified,  i.e.,  the  resource  requirement  instead  requests  a  model  type  or  resource  class,  then  the 
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default  resource  configuration  (named  :  default)  is  used.  If  there  is  no  default  configuration, 
a  single  instance  is  assumed  to  be  sufficient. 

If  more  than  a  single  cargo-spec  is  defined  within  a  configuration,  an  operatorcan  be  specified 
to  indicate  how  the  multiple  cargo-specs  should  be  treated  when  used  to  determine  the  required 
number  of  resources  for  a  particular  cargo  manifest.  There  are  two  operators:  :  and  and  :or.27 
The  use  of  an  operator  facilitates  a  richer  representation  of  configurations,  by  allowing  for  the 
case  where  a  resource  can  be  set  up  in  such  a  way  as  to  accommodate  different  combinations 
of  cargo  at  the  same  time,  instead  of  only  one  (i.e.,  configuration  C-|  can  handle  a  maximum 
of  6  PALLETS,  while  configuration  C2  can  handle  a  maximum  of  20  PAX  and  2  vehicles.  If  no 
operator  is  specified,  the  default  (i.e.,  :or)  is  used. 

The  configuration  specification  format  is  presented  in  Table  30. 


Table  30:  Resource  configuration  specification  format 


Grammar  for  configurations-spec 

Notes 

configurations-spec  — >  <configurations> 

[1 configuration-spec ] + 

</ conf i gu  rati ons> 

configuration-spec  —¥  configuration  name-spec  [operator-spec]  > 

[cargo-spec]^ 

a 

</ conf i gu  rati on> 

name-spec  —¥  name=(  default”  |  “capability-name”  ) 

b 

operator-spec  — >  op=(“or”  |  “and”) 

c 

a:  for  cargo-spec  grammar,  see  Table  17,  page  94 

b:  capability-name  names  a  capability  (if  it  does  not  yet  exist,  it  will  be  created) 
c:  the  :  and  operator  is  not  currently  supported 


27Note  that  the  : and  operator  is  not  currently  supported  byCoMiREM. 
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A.3.2  Capacity 

The  capacity  specification  describes  the  availability  of  a  resource  over  time,  and  is  generally 
defined  at  the  instance  level.  Capacity  is  specified  as  a  sequence  of  (typically)  contiguous  (but 
always  non-overlapping)  time  intervals  indicating  how  many  units  of  a  resource  are  available  for 
allocation  by  the  scheduler  at  any  point  in  time.  Comirem  currently  supports  the  definition  of 
unitary-capacity,  reusable  resources,  i.e. ,  they  provide  one  unit  of  capacity  and  become  available  for 
reuse  after  completing  any  service  to  which  they  have  been  allocated.  An  activity  may,  however, 
require  more  than  a  single  unit  of  capacity,  in  which  case  multiple  resource  instances  will  be 
required. 

Each  capacity  interval  includes  a  start-ti  me  and  end-ti  me  tag,  the  value  ofwhich  may  be  a 
valid  time- spec,  or  one  of  the  special  keywords:  :  negati  ve-i  nfi  ni  ty  or  i  nfi  ni  ty,  which  rep¬ 
resent  unbounded  negative  and  positive  times,  respectively.28  The  capacity  specification  format 
is  presented  in  Table  31 . 


Table  31 :  Capacity  specification  format 


Gram  m  ar  for  capacity-spec 

Notes 

capacity-spec 

<capacity-list> 

[i capacity-interval-spec ] + 

</ capaci ty-1 i st> 

capacity-interval-spec 

<capaci ty-i nte  rval > 

start-spec  end-spec  units-spec 
</ capaci ty-i nte  rval > 

start-spec 

<start-time> 

( time-spec  |  “:negative-infinity”  ) 

a 

</start-time> 

end-spec 

<end-time> 

( time-spec  |  infinity”) 

a 

</end-time> 

units-spec 

<units>  integer  </units> 

b 

a:  for  time-spec  grammar,  see  Table  11,  page  90 

b:  at  the  present  time,  the  uni  ts  integer  value  must  be  1  (one). 


28Note  that  all  time  intervals  must  be  positive  (i.e.,  : negative-infinity  <  start-time  <  end-time  <  infinity). 
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A.3.3  Uncapacitated  Place  Components 

Uncapacitated  place  components  are  generally  defined  at  the  instance  level,  and  only  for  pi  ace 
resources.  Anyplace  resource  may  provide  a  bucket  of  uncapacitated  resource  capacity,  speci¬ 
fied  in  terms  of  capabilities,  model  types  and  resource  classes. 

The  uncapacitated  place  component  specification  format  is  presented  in  Table  32. 


Table  32:  Uncapacitated  place  components  specification  format 


Gram  m  ar  for  uncapacitated-components-spec 

Notes 

uncapacitated-components-spec  — >  <uncapacitated-components> 

capabilities-spec 

resource-class-spec 

model-type-spec 

</uncapaci tated-components> 

capabilities-spec  — >  <capabilities> 

[i capability-name ] + 

a 

</capabilities> 

resource-class-spec  — >  <resource-class> 

[. resource-class-name ] + 

b 

</resource-cl ass> 

model-type-spec  — >  <model  -type> 

[model-  type] + 

c 

</model -type> 

a:  capability-name  names  a  capability  (if  it  does  not  yet  exist,  it  will  be  created) 
b:  resource-class-name  must  refer  to  a  predefined  resource  class 
c:  model-type  must  refer  to  a  predefined  model  type 
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A.4  Capabilities 

Capability  specifications  appear  in  the  s/tw^t/on-capabi li ties. xml  file,  and  define  capabilities 
that  are  linked  to  resource  classes  within  a  particular  situation  for  reference  by  both  the  activity 
types  in  that  situation  and  the  activity  instances  in  a  particular  scenario. 

The  type- ref  value  of  the  type-ref-spec  entry  maybe  either  move  or  event.  The  purpose  of  this 
entry  is  to  inform  the  system  about  the  nature  of  the  capability  being  defined  (i.e.,  movement 
capabilities  are  for  moves,  while  stationary  capabilities  are  for  events). 

The  capabilities  specification  format  is  presented  in  Table  33. 


Table  33:  Capability  specification  format 


Gram m ar  for  capability-spec 

Notes 

capability-spec  — >  capability  name-spec> 

capable-types-spec  type-ref-spec 
</capability> 
name-spec  — >  name=“SYMBOi_” 

capable-types-spec  — >  <capabl  e-types> 

[. resource-class-name ] + 

</capabl e-types> 

type-ref-spec  — Y  <type-ref>  (move  event)  </type-ref> 

a 

a:  resource-class-name  must  refer  to  a  predefined  resource  class 
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A. 5  Plan  Configuration 

The  plan-configuration  specification  appears  at  the  start  of  the  scenario- pi  an .  xml  file,  ahead  of 
the  scenario-specific  place,  activity  and  constrai nt  instances.  It  provides  mostly  temporal 
information  about  the  plan  to  facilitate  its  processing  by  Comirem. 

The  plan-configuration  specification  format  is  presented  in  Table  34. 


Table  34:  Plan-configuration  specification  format 


Gram  m  ar  for  plan-configuration-spec 

Notes 

plan-configuration-spec  — >  <configuration> 

[display-name-spec] 

[calendar-zero-spec] 

[calendar-zero-date-spec] 

[ref-hours-spec] 

a 

[plan-horizon-spec] 

[time-granularity-spec] 

</ conf i gu  rati on> 

display-name-spec  — >  <di  spl  ay-name>  text  </di  spl  ay-name> 

calendar-zero-spec  — >  <cal endar-zero>  integer  </cal endar-zero> 

calendar-zero-date-spec  — y  <cal  endar-zero-date> 

time-spec 

b 

</cal endar-zero-date> 

plan-horizon-spec  — >  <pl  an-hori  zon>  interval-spec  </pl  an-hori  zon> 

c 

time-granularity-spec  — ¥  <ti  me-g  ranul  ari  ty> 

time-granularity 

</ti me-g ranul ari ty> 

time-granularity  — y  seconds  |  minutes  |  hours  days 

a:  for  ref-hours-spec  grammar,  see  Table  19,  page  96 
b:  for  time-spec  grammar,  see  Table  11 ,  page  90 
c:  for  interval-spec  grammar,  see  Table  12,  page  91 
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B  COMIREM  User  Manual 


The  Comirem  system  consists  of  two  components:  a  server  and  a  client.  The  server  is  a  self- 
contained  executable  program  running  a  Common  Lisp-based,  HTTP-compliant  web  server. 
The  client  is  an  HTML  file  that  contains  an  embedded  Shockwave  application. 


B.1  Installation 

To  install  Comirem  on  a  Microsoft  Windows-based  computer,  run  the  installation  program: 
COMIREMInstaller.exe.  This  will  install  the  Comirem  system  onto  your  computer  (by  default, 
all  files  will  be  placed  in  the  C:\Program  Files\Comi  rem  directory)  and  establish  all  necessary 
environment  variables  (namely,  0Z0NE_H0ME). 

On  an  Apple  Macintosh  or  Sun  Solaris  platform,  Comirem  is  launched  from  within  a  Franz 
Allegro  Common  Lisp  session,  with  the  necessary  Ozone  and  Comirem  code  loaded  and  the 
OZONEJHOME  environment  variable  properly  set.29 


B.2  Starting  Comirem 

To  start  Comirem  in  a  Windows  environment,  execute  Comi  rem .  exe.  In  a  Macintosh  or  Solaris 
environment,  execute  the  start-comi  rem  function  from  inside  a  properly  initialized  Common 
Lisp  session.  This  will  start  the  server,  which  is  then  ready  to  accept  connections  on  port  8000. 30 

To  run  the  client,  open  C0MIREM.htm  in  any  Internet  browser  equipped  with  an  up-to-date 
Shockwave  plug-in.31 


B.3  Running  Comirem 

We  begin  with  a  description  of  the  buttons  at  the  top  of  the  Activity  Network  Display  (the  initial 
Comirem  display).  These  buttons,  shown  in  Figure  57,  provide  basic  functionality  for  operating 
the  Comirem  client. 


SET  SERVER  I  LOAD  I  SAVE  |  NAVIGATION  I  ffEf  HOUR  I 


AUTD- ALLOCATE  I  UNDO 


Figure  57:  Comirem  GUI  navigational  buttons 


Note  that  the 


NAVIGATION 


and 


REF  HOUR 


buttons  are  discussed  within  the  context  of  the 


Activity  Network  Display,  in  Sections  B.4.1.1  and  B.4.1.6,  respectively. 


29ln  the  absence  of  an  executable  file,  the  source  code  can  be  loaded  into  an  Ozone-initialized  Lisp  environment 
using  the  Ozone- provided  load-comi  rem  function. 

30Note  that  when  starting  from  within  a  Common  Lisp  session,  the  function  start-comi  rem  accepts  a  :  PORT 
keyword  argument  for  specifying  the  desired  port  number  (which  defaults  to  8000). 

31  Note  that  Netscape  version  6.0  does  not  support  Shockwave. 
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B.3.1  SET  SERVER  Button 


The  first  step  is  to  establish  communication  between  the  Comirem  client  and  the  server.  When 
started,  the  Set  Server  pop-up  window  will  appear,  as  shown  in  Figure  58. 32  The  default  settings 
assume  that  both  the  server  and  client  are  running  on  the  same  computer.  If  this  is  the  case, 
leave  the  default  settings  unchanged  and  press  |  apply  |.  If  not,  set  the  host  ip  and  port  fields  to 


the  IP  address  and  port  where  the  Comirem  server  is  running  and  then  press 


APPLY 


Set.  these  to  the 
IP  and  Port  the 
COMIREM  server 
is  running  an, 

Da  not  change 
default  settings 
If  the  COMIREM 
server  is  running 
an  this  computer. 


Figure  58:  Set  Server  pop-up  window 


B.3.2  LOAD  Button 


The  next  step  is  to  load  a  scenario  and  any  number  of  plans.  Pressing  the  |  load  |  button  will 
open  the  Load  pop-up  window  shown  in  Figure  59.  One  scenario  and  any  number  of  plans  can 
be  loaded  at  any  time.  Scenarios  define  the  available  resource  types,  capabilities  and  resource 
bed-down  information  (i.e.,  available  resource  and  place  instances).  Plans  define  the  activities, 
constraints  and  plan-specific  places  that  comprise  the  activity  network.33 

When  the  Load  pop-up  window  appears  for  the  first  time,  only  scenarios  are  listed.  Once  a 
scenario  is  selected,  a  list  of  the  plans  appropriate  for  the  selected  scenario  appears  in  the  list  on 
the  right.  The  scenario  and  plan(s)  that  are  already  loaded  are  highlighted  in  red.  Any  number 
of  plans  may  be  selected.  Selected  scenario  and  plan(s)  are  highlighted  in  red.  To  unselect,  click 
on  any  highlighted  scenario  or  plan. 

The  Load  pop-up  window  provides  four  menu  options  for  loading  data  files: 


LOAD  FROM  SCRATCH 


Loads  the  selected  scenario  and  plan(s),  disposing  of  any  existing  context 


ADJUST  PLANS 


Loads  the  selected  plan(s)  into  the  current  scenario  and  removes  any  deselected  plans 


SET  SERVER 


32This  pop-up  window  can  be  accessed  at  anytime  by  pressing  the 
33 All  scenario  and  plan  files  are  located  in  the  OZONE.HOME/data/comi  rem  directory. 


button. 


Ill 


Figure  59:  Load  pop-up  window 


CONNECT  AS  IS 


Connects  to  the  server  and  retrieves  the  activity  network  in  its  current  state  (this  is  useful 
if  the  user  has  closed  and  then  reopened  the  browser,  intending  to  continue  from  where 
they  left  off) 


CANCEL 


Exits  the  Load  pop-up  window  without  loading  any  scenario  or  plan(s) 


B.3.3  SAVE  Button 

Saving  a  schedule  is  not  actively  supported  through  the  Comirem  GUI  at  this  time. 


B.3.4  AUTO-ALLOCATE  Button 


Pressing  the 


AUTO-ALLOCATE 


button  causes  the  server  to  attempt  to  schedule  all  currently  un¬ 


scheduled  activities  in  the  currently  loaded  plan.  The  server  will  not  schedule  any  activities  with 
conflicts  (see  Section  B.4.1). 


B.3.5  UNDO  Button 


As  the  name  implies,  the 
any  consequences  of  that  action. 


UNDO 


button  undoes  the  last  action  taken  by  the  user  and  discards 


B.4  Client  Components 

The  Comirem  GUI  client  is  comprised  of  four  principle  displays:  the  Activity  Network  Display, 
the  Resource  &  Taskforce  Manager,  the  Place  Manager,  and  the  Magboard.  Access  to  each 
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display  is  obtained  by  clicking  on  its  name  in  the  client  component  selector,  which  is  included 
at  the  bottom  of  each  display  and  shown  in  Figure  60. 


Figure  60:  GUI  client  component  selector 

In  the  remainder  of  this  section,  we  describe  the  features  of  each  of  these  four  displays. 

B.4.1  Activity  Network  Display 

Once  a  scenario  and  plan(s)  are  loaded,  the  Activity  Network  Display  is  populated  with  the 
collective  activity  network  (i.e.,  the  network  comprising  all  loaded  plans)  and  is  automatically 
displayed.  The  Activity  Network  Display  can  be  presented  in  two  different  formats:  the  (de¬ 
fault)  Gantt  View  described  in  Section  B.4.1. 2,  and  the  Vector  View  described  in  Section  B.4.1. 3. 
All  components  of  the  activity  network  are  colored  according  to  their  status,  as  described  in 
Section  B.4.1. 4. 


B.4.1 .1  NAVIGATION  Button 

Alternation  between  the  two  views  of  the  Activity  Network  Display  is  achieved  using  the  Naviga¬ 
tion  pop-up  window  shown  in  Figure  61 ,  which  is  reached  by  clicking  on  the  top-level 
button.  The  magnifying  glass  buttons  zoom  in  and  out  on  the  activity  network.  To  zoom 
to  the  scale  at  which  the  entire  temporal  horizon  of  the  activity  network  is  visible,  press  the 
button.  The  result  of  this  action  only  ensures  that  the  entire  activity  network 
fits  horizontally  in  the  display— not  vertically  (i.e.,  it  may  still  be  necessary  to  scroll  up  and  down 
to  see  activities  outside  of  the  screen). 

The  Viewport  displays  a  miniature  version  of  the  entire  activity  network.  Clicking  on  a  point 
within  it  re-centers  the  Activity  Network  Display  (either  the  Gantt  or  Vector  View )  on  that  point. 
The  Viewport  utilizes  the  same  color  coding  as  the  Activity  Network  Display.  The  toggle  switch 
for  alternating  between  the  Gantt  View  and  Vector  View  is  located  below  the  Viewport.  Below  that, 
depending  on  the  current  view,  is  a  final  option  for  modifying  the  display.  In  the  Vector  View, 
the  user  can  choose  between  displaying  the  activity  network  using  earliest  finish  times  (EFTs) 
or  latest  finish  times  (LFTs,  the  default).  In  the  Gantt  View,  the  user  can  choose  between  an 
enhanced  and  a  standard  temporal  display  (this  is  discussed  in  Section  B.4.1 .2). 


SHOW  ALL  TIMES 


NAVIGATION 


B.4.1. 2  Gantt  View 


In  the  Gantt  View,  shown  in  Figure  62,  each  activity  and  thread  in  the  activity  network  is  repre¬ 
sented  by  a  single  horizontal  bar.  Places  are  not  shown.  Threads  are  represented  by  purple  bars 
and  only  their  start  and  finish  times  are  displayed.  The  constituent  activities  of  each  thread  are 
displayed  underneath  it,  sorted  by  start  time,  and  the  thread  can  be  collapsed  or  expanded  by 
clicking  on  its  name.  Within  each  activity  bar,  the  lighter  color  represents  the  overall  time  win¬ 
dow  within  which  an  activity  must  be  completed,  and  the  darker  color  represents  the  duration 
of  the  activity.  As  mentioned  above,  toggling  the  |  rich  times~|  button  in  the  Navigation  pop-up 
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Navigation  Popup  Windows 


Vector  Display 


Gantt  Display 


Figure  61 :  Vector  View  and  Ccintt  View  display  panes  for  the  Navigation  pop-up  window 


window  switches  between  an  enhanced  temporal  display  and  the  standard  (default)  format.  In 
the  enhanced  format,  each  activity  bar  shows  both  its  earliest  and  latest  start  times  (also  called 
“no  earlier  than”  or  NET  time,  and  “no  later  than”  or  NLT  time,  respectively),  earliest  and  latest 
end  times  and  its  minimum  and  maximum  duration,  as  explained  in  Figure  63. 

B.4.1.3  Vector  View 

The  Vector  View  of  the  Activity  Network  Display  is  shown  in  Figure  64.  It  depicts  a  basic  “plan- 
oriented”  visualization  of  an  activity  network  and  has  been  adapted  from  other  current  SOF 
planning  tools.  Horizontal  bars  are  used  to  indicate  an  activity  (or  more  generally,  a  sequence  of 
activities)  taking  place  at  a  particular  location  overtime,  and  diagonal  bars  are  used  to  indicate 
movement  (or  transport)  between  locations.  Threads  are  currently  not  displayed  in  the  Vector 
View. 

B.4.1.4  Color  Legend 

The  color  legend  for  the  Activity  Network  Display  is  presented  in  Figure  65. 
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Figure  62:  Activity  Network  Display  ( Gantt  View ) 


Dissection  of  Rich  Times  Gantt  Bars 


End  Times: 


End  No  Earlier  Than  (NET]  End  No  Later  Than  (NLT) 


Durations: 

Start  of  Duration  Minimum  Duration  Maximum  Duration 


Figure  63:  Details  of  the  enhanced  temporal  display  in  the  Gantt  View 
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Figure  64:  Activity  Network  Display  ( Vector  View) 


Color  Legend 


Green.  Activities  whose  resource  requirements  are  satisfied  or 
activities  that  do  not  have  resource  requirements.  These  activities 
can  be  considered  "scheduled"  and  do  not  typically  need  further 
attention. 


Yellow.  Activities  whose  resource  requirements  are  have  not  yet 
been  satisfied.  These  activities  are  considered  ''unscheduled'". 
Select  these  activites  individually  and  choose  a  scheduling  option 
or  allow  the  server  to  attempt  to  choose  a  scheduling  option  for  all 
unscheduled  activities  by  pressing  the  AUTO- ALLOCATE  button. 


Red.  Conflicts.  Activities  whose  resource  requirements  can  not 
be  satisified  as  defined  by  the  plan.  Select  these  activities  and 
choose  a  resolution.  The  server  can  not  attempt  to  choose  a 
scheduling  option  for  conflicts. 


Grey.  Activities  created  by  the  server  to  satisfy  resource 
requirements  not  specified  by  the  plan  (such  as  positioning  and 
de  positioning  moves  for  certain  platforms).  These  can  be  selected 
and  viewed,  but  no  further  actions  are  typically  necessary. 


Figure  65:  Activity  Network  Display  color  legend 
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B.4.1 . 5  Selected  Activity  Form 

An  activity  (or  thread)  can  be  selected  in  the  Gantt  View  by  clicking  on  its  corresponding  bar. 
In  the  Vector  View,  an  activity  is  selected  by  positioning  the  cursor  over  the  desired  activity  (or 
multiple  collocated  activities),  at  which  point  a  yellow  pop-up  menu  will  appear  to  the  right  of 
the  cursor  listing  all  of  the  activities  within  close  range.  The  desired  activity  is  selected  by  first 
clicking  and  holding  down  the  mouse  button  to  secure  the  pop-up  menu,  positioning  the  cursor 
over  the  name  of  the  desired  activity,  and  finally  releasing  the  mouse  button.  Figure  66  depicts 
the  middle  step  in  this  process. 


Figure  66:  Selecting  an  activity  in  the  Vector  View  of  the  Activity  Network  Display 

When  an  activity  or  thread  is  selected,  the  Selected  Activity  form  at  the  bottom  of  the  Activity 
Network  Display  is  automatically  populated  with  the  data  for  the  selected  object,  as  shown  in 
Figure  67. 


Figure  67:  Information  about  a  selected  activity  in  the  times  &  information  pane  of  the  Selected 
Activity  form  in  the  Activity  Network  Display 
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The  Selected  Activity  Form  consists  of  five  panes  to  convey  information  to  the  user  and  facilitate 
interaction.  Each  of  these  panes  is  accessible  using  the  thumb-toggle  interface  on  the  left-hand 
side  of  the  form: 


TIMES  &  INFORMATION 


As  shown  in  Figure  67,  this  pane  conveys  all  temporal  and  general  information  for  an 
activity  or  thread.  For  activities  and  threads,  this  includes  the  start  and  end  times  and 
a  description  of  the  object.  For  activities,  it  also  includes  duration,  anchor  and  ref-hour 
constraints,  positioning,  manifest  and  actor  (i.e.,  an  assigned  taskforce)  information,  and 
a  pull-down  menu  of  feasible  scheduling  options.  For  threads,  it  also  includes  a  pull-down 
menu  of  feasible  taskforce  assignments. 


An  activity  can  be  scheduled  by  selecting  a  scheduling  option  from  the  available  options 
pull-down  menu.  A  taskforce  can  be  assigned  to  a  thread  using  the  same  menu. 


It  is  possible  to  override  the  latest  finish  time  (LFT),  or  end  nlt  (i.e.,  end  no  later  than) 
time,  of  a  selected  activity  by  establishing  an  anchor  on  that  time  point.  An  NLT  anchor 
further  constrains  the  latest  finish  time  dictated  by  the  underlying  temporal  network  by 
introducing  a  new  hard  upper-bound  constraint  fixed  at  a  certain  time.  To  set  an  anchor, 
simply  edit  the  time  in  the  end  nlt  field  and  press  the  |  edit |  button.  The  Activity  Net¬ 


work  Display,  Selected  Activity  form,  and  most  importantly,  the  selected  activity’s  feasible 
scheduling  options,  will  all  be  updated  accordingly.  When  an  anchor  is  set,  a  small  red 
anchor  icon  appears  above  the  end  nlt  time,  as  depicted  in  Figure  68.  An  anchor  can  be 
removed  by  clicking  on  the  anchor  icon.34 


Figure  68:  Setting  an  NLT  anchor  on  a  selected  activity  in  the  times  &  information  pane  of  the 
Selected  Activity  form  in  the  Activity  Network  Display 


In  the  Vector  View  of  the  Activity  Network  Display,  anchors  are  represented  by  a  purple 
line/icon  extending  up  from  the  end  of  the  activity  to  the  anchor  time.  In  the  Gantt  View, 
the  length  of  the  bar  for  the  activity  is  adjusted  to  account  for  an  anchor  (i.e.,  there  is  no 
special  icon). 


resource  requirements 


The  resource  requirements  pane,  depicted  in  Figure  69,  provides  the  means  for  interac¬ 
tively  modifying  the  resource  requirements  for  an  activity.  The  feasible  scheduling  options 


34The  setting  of  EST,  LST  and  EFT  anchors  is  not  currently  supported  in  the  Comirem  GUI,  although  these  anchor 
types  are  supported  by  Comirem  itself. 
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in  the  available  options  pull-down  menu  can  be  changed  by  relaxing  or  tightening  the 
requirements  in  this  pane. 


Figure  69:  Resource  requirements  for  a  selected  activity  in  the  resource  requirements  pane  of 
the  Selected  Activity  form  in  the  Activity  Network  Display 


The  feasible  scheduling  options  for  an  activity  are  initially  constrained  by  the  set  of  al¬ 
lowable  resource  classes  indicated  by  the  highlighted  platforms  in  this  pane.  The  set  of 
platforms  (i.e.,  resource  classes)  is  determined  by  selecting  and  deselecting  capabilities, 
models  and  platforms.  (Selected  items  are  highlighted  in  red  italics.)  Changes  in  one 
column  may  affect  the  selections  in  other  columns.  The  semantics  of  this  process  are  as 
follows.  Referring  back  to  Figure  16,  Section  3. 2. 2.1  (The  Resource  Requirement  Hierar¬ 
chy)-  page  29,  the  hierarchy  puts  capabilities  at  the  top  and  resource  classes  (platforms) 
at  the  bottom.  Whenever  a  capability,  model  or  platform  is  selected  (or  deselected),  its 
children  are  selected  (deselected)  as  well.  The  highest  level  at  which  any  item  is  specified 
controls  the  selection  process.  If  two  items  at  the  same  level  are  selected,  the  union  of 
their  descendents  (i.e.,  platforms  and  possibly  models)  is  selected.  If  a  selection  is  made 
at  a  higher  level,  only  its  descendents  will  remain  selected.  If  an  item  is  deselected,  its  descen¬ 
dents  are  deselected  unless  they  remain  feasible  owing  to  the  reapplication  of  the  selection 
semantics. 


Thel  revertto  original  requirements  I  button  can  be  used  to  restore  the  original  resource- 
requirement  specifications  at  anytime.  Similarly,  an  activity  can  be  scheduled  by  selecting 
a  scheduling  option  from  the  available  options  pull-down  menu. 


GOALS  &  PRIORITIES 


This  pane  is  intended  to  allow  the  user  to  specify  goals  and  priorities  for  an  activity  to 
affect  its  treatment  by  the  scheduler.  This  feature  is  not  currently  supported. 


MESSAGE  HISTORY 


This  pane  is  intended  to  provide  a  history  of  all  decisions  and  scheduling  actions  involving 
an  activity.  This  feature  is  not  currently  supported. 


CONFLICT  RESOLUTION 


It  is  possible  for  the  server  to  determine  that  an  activity  cannot  be  completed  within  the 
time  constraints  defined  by  the  plan  given  the  activity’s  specified  resource  requirements. 


119 


These  activities  are  considered  to  be  in  conflict  and  are  displayed  in  red  in  the  Activity  Net¬ 
work  Display.  For  a  conflicted  activity,  the  conflict  resolution  pane,  shown  in  Figure  70, 
provides  a  description  for  the  conflict  and  the  means  available  for  its  resolution. 


Figure  70:  Conflict-resolution  options  fora  selected  (conflicted)  activity  in  the  conflict  resolu¬ 
tion  pane  of  the  Selected  Activity  form  in  the  Activity  Network  Display 

The  available  resolutions  pull-down  menu  provides  a  list  of  available  resolution  options 
for  the  conflicted  activity.  When  a  resolution  from  this  list  is  selected,  the  conflict  is  re¬ 
solved  and  feasible  scheduling  options  can  again  be  determined  for  the  activity. 


B.4.1.6  REF  HOUR  Button 


As  described  in  Section  3. 2. 3. 2  (Reference  Hour  Constraints),  activities  can  be  linked  to  plan- 
specific  ref-hours.  A  ref-hour  is  centered  on  a  specific  point  in  time,  and  all  activities  linked 
to  it  (via  their  start/end  times)  share  its  temporal  flexibility.  A  ref-hour  defines  preferred  times 
for  an  activity,  lying  within  its  [EST..LST]  and  [EFT..LFT]  ranges.  Referring  back  to  Figure  68 
(page  118),  note  that  the  link  to  ref-hour  H-2  results  in  a  preferred  start  time  of  1857  and  a 
preferred  end  time  of  2041  for  the  selected  activity.  Not  all  activities  are  linked  to  ref-hours,  and 
not  all  plans  have  ref-hours. 

Pressing  the 


ref  hour 


button  opens  the  Ref  Hour  Configuration  pop-up  window  depicted  in 
Figure  71.  From  this  window,  a  ref-hour  can  be  selected  to  access  its  time,  temporal  flexibility, 
and  all  activities  linked  to  it.  The  time  and  flexibility  of  the  selected  ref-hour  can  be  modified  in 
the  time  and  flexibility  fields,  respectively.  When  the  |  apply  |  button  is  pressed,  all  changes  are 


applied  to,  and  propagated  throughout,  the  activity  network. 


B.4.1.7  Execution  Results 

Comirem  processes  execution  results  by  accepting  actual  execution  times  (also  referred  to  as  call- 
times)  in  its  situation  files  and  interpreting  them  as  hard  temporal  constraints  (i.e.,  immovable 
anchors)  on  the  start/end  times  of  both  executed  and  in-process  activities.  The  latest  calltime 
determines  the  value  of  the  current-time  clock  in  Comirem.  When  calltimes  are  specified  for  a 
given  situation,  the  plan  is  considered  to  be  in  progress,  and  the  latest  calltime  is  marked  in 
the  Activity  Network  Display  with  a  vertical  red  line,  as  shown  in  Figure  72.  The  portion  of  the 
screen  to  the  left  of  this  line  is  shaded  in  gray,  indicating  that  all  activities  executing  in  this  region 
are  considered  to  have  completed  or  be  in-process.35 

35Note  that  this  implements  a  rather  simple  model  for  processing  execution  results:  if  a  start  calltime  has  not 
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Figure  71 :  Ref  Hour  Configuration  pop-up  window 


Figure  72:  The  latest  calltime  reflected  in  the  Gantt  View  of  the  Activity  Network  Display 


121 


B.4.2  Resource  &  Taskforce  Manager 

The  Resource  &  Taskforce  Manager  provides  access  to  the  available  resources  and  taskforces 
within  a  given  scenario,  to  facilitate  their  creation,  viewing  and  modification.  The  Resource 
&  Taskforce  Manager  provides  two  separate  forms:  one  for  resource-capacity  and  attribute 
manipulation  (the  Resource  Manager)  and  one  fortaskforce  manipulation  (the  Taskforce  Manager). 
Note  that  currently,  the  scope  of  any  modifications  made  using  these  forms  is  limited  to  the 
current  planning/scheduling  session,  that  is,  any  changes  made  here  cannot  yet  be  saved  to  a 
file. 


B.4.2.1  Resource  Manager 


The  Resource  Manager,  depicted  in  Figure  73,  provides  a  form  for  viewing  resource  capacity,  edit¬ 
ing  resource  attributes,  and  creating  and  deleting  resource  instances.  On  the  left  side  of  the 
form,  the  available  resources  column  lists  all  known  resources,  sorted  and  indexed  by  model 
and  platform.  Clicking  on  any  model,  platform,  or  resource  causes  its  capacity  line  to  be  dis¬ 
played  in  the  utilization  window  on  the  lower  right  side  of  the  form.  The  utilization  window 
displays  the  entire  time  horizon  for  the  loaded  plan(s),  and  includes  one  row  for  each  instance 
corresponding  to  the  item  (e.g.,  model,  platform,  resource)  selected.  The  red  blocks  represent 
used  capacity  (i.e.,  indicating  existing  reservations),  while  the  gray  blocks  represent  available 
capacity. 

In  the  upper  right  side  of  the  form,  the  resource  edit  table  facilitates  the  creation,  editing 
and  deletion  of  individual  resource  instances.  The  |  add  |  button  opens  a  pop-up  window  into 


which  the  necessary  resource-attribute  values  are  entered  (concluded  by  pressing  the  accompa¬ 
nying  apply  |  button).  The 


EDIT 


button  works  similarly,  opening  the  aforementioned  pop-up 
window  with  already  populated  attribute  values  that  can  be  edited  (and  again  concluded  by 
pressing  the  accompanying  [apply  |  button).  (A  [cancel 


delete 


button  is  also  provided  in  this  pop-up 
button  deletes  the  currently  selected 


window  to  abort  a  creation  or  editing  event.)  The 
(i.e.,  highlighted)  resource  (note:  without  confirmation).  As  with  all  other  data-manipulation  op¬ 
erations,  any  creation,  edit  or  deletion  may  affect  the  feasible  scheduling  options  for  activities 
elsewhere  in  the  network. 


B.4.2. 2  Taskforce  Manager 

The  Taskforce  Manager,  depicted  in  Figure  74,  provides  a  form  for  editing,  modifying  and  deleting 
taskforces.  As  in  the  Resource  Manager,  the  available  resources  column  on  the  left  side  of  the 
form  lists  all  known  resources,  organized  by  model  type  and  resource  class.  The  taskforces 
column  on  the  right  lists  all  known  taskforces  and  their  existing  constituent  resources.  New 
taskforces  can  be  created  in  the  add  taskforce  window  in  the  lower  right  corner  of  the  form  by 
entering  a  name  and  pressing  the  |  create  |  button.  Taskforce  manipulation  is  performed  using 


been  received  for  an  activity  by  the  time  its  start  time  (either  scheduled  or  not)  has  passed,  it  is  assumed  to  be 
executing  within  its  assigned  time  window;  if  an  end  calltime  has  not  been  received  for  an  activity  by  the  time 
its  end  time  (again,  either  scheduled  or  not)  has  passed,  it  is  assumed  to  have  executed.  A  more  sophisticated 
model  would  allow  for  activities  that  have  not  received  their  expected  calltimes  to  be  rescheduled  according  to 
the  presumably  tightened  situation.  Decisions  on  how  to  interpret  execution  results  can  be  expected  to  differ  by 
domain  and  possibly  additional  environmental  factors. 
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Figure  73:  Resource  &Taskforce  Manager  ( Resource  Manager  Form ) 

a  drag-and-drop  approach.  To  assign  a  resource  to  a  taskforce,  select  it  with  the  mouse  and 
drag  it  onto  the  name  of  the  desired  taskforce  (as  depicted  in  Figure  75).  To  move  a  resource 
from  one  taskforce  to  another,  select  the  resource  in  the  taskforces  column  and  drag  it  onto 
the  name  of  the  desired  taskforce  (also  in  the  taskforces  column).  This  step  is  depicted  in  the 
left  side  of  Figure  76.  To  delete  a  taskforce  or  remove  a  resource  from  a  taskforce,  select  the 
resource  or  taskforce  from  the  taskforces  column  and  drag  it  to  the  deletion  area  immediately 
below  the  taskforces  column.  This  step  (for  a  taskforce  deletion)  is  depicted  in  the  right  side  of 
Figure  76. 

The  hide  resources  already  assigned  to  a  taskforce  radio  button  located  below  the  AVAIL¬ 
ABLE  resources  column  controls  whether  resources  in  the  available  resources  column  are  dis¬ 
played  in  that  column  once  they  have  been  assigned  to  a  taskforce.  While  resources  can  be 
assigned  to  multiple  taskforces  whose  time  windows  do  not  intersect,  it  is  often  the  case  that 
resources  are  assigned  to  just  a  single  taskforce,  in  which  case  the  interface  can  be  streamlined 
by  removing  those  resources  once  they  have  been  assigned. 


123 


Figure  74:  Resource  &Taskforce  Manager  ( Taskforce  Manager  Form ) 
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Adding  to  a  Taskforce 


Figure  75:  Taskforce  management:  assigning  a  (personnel)  resource  to  a  taskforce 


B.4.3  Place  Manager 


The  Place  Manager,  depicted  in  Figure  77,  provides  a  form  for  viewing  place  capacity  and  cre¬ 
ating,  editing  and  deleting  places.  Similar  to  the  layout  of  the  Resource  Manager,  this  form 
includes  an  available  places  column  on  the  left  side  that  lists  all  known  places.  In  the  lower 
right  corner,  the  utilization  window  displays  the  capacity  of  a  selected  place.  In  the  upper 
right  corner,  there  are  two  editing  forms:  one  for  platform  allocation  (the  platform  allocation 
table),  and  another  for  place  capacity  (the  place  capacity  table). 

The  platform  allocation  table  displays  the  allocation  of  platform  instances  to  places,  or¬ 
ganized  by  platform-to-place  pairings  (i.e.,  there  may  be  multiple  rows  for  each  platform  and 
each  place  in  this  table).  The  |  add  |  button  opens  a  new  table  row  into  which  a  known  platform 


name,  a  known  place  name  and  a  quantity  are  entered  (concluded  by  pressing  the  accompany¬ 
ing  apply  button).  The 


EDIT 


button  works  similarly,  opening  a  table  row  with  already  popu¬ 
lated  attribute  values  that  can  be  edited  (and  again  concluded  by  pressing  the  accompanying 
button).  Again,  a 


APPLY 


CANCEL 


button  aborts  either  a  creation  or  editing  event.  The 


DELETE 


button  deletes  the  currently  selected  (i.e.,  highlighted)  platform/place  entry  (again  note:  without 
confirmation). 

The  place  capacity  table  displays  place  capacity,  organized  by  place-to-component-type  pair¬ 
ings  (i.e.,  there  maybe  multiple  rows  for  each  place  and  each  component-type  in  this  table).  The 
add  button  opens  a  new  table  row  into  which  a  known  place  name,  a  known  component-type 
name  and  a  quantity  are  entered  (concluded  by  pressing  the  accompanying  [apply  |  button).  An 


unconstrained  checkbox  facilitates  the  specification  of  unconstrained  component-types.  The 


EDIT 


can  be  edited  (and  again  concluded  by  pressing  the  accompanying 

apply  button).  Again,  a 

CANCEL 

button  aborts  either  a  creation  or  editing  event.  The 

DELETE 

button  deletes  the  cur- 
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Modifying  a  Taskforce 


Deleting  a  Taskforce 


Figure  76:  Taskforce  management:  (left)  modifying  a  taskforce  by  deleting  a  member  or  moving 
it  to  another  taskforce;  (right)  deleting  a  taskforce 
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Figure  77:  Place  Manager 


rently  selected  (i.e.,  highlighted)  place/component-type  entry  (again  note:  without  confirmation). 

And  again,  as  with  all  other  data-manipulation  operations,  any  creation,  edit  or  deletion 
may  affect  the  feasible  scheduling  options  for  activities  elsewhere  in  the  network. 

B.4.4  Magboard 

The  Magboard,  depicted  in  Figure  78,  is  a  tool  for  displaying  the  location  of  resources  overtime. 
Places  are  represented  by  squares  on  the  grid,  which  is  laid  out  in  a  simplified  geographic  format. 
At  any  point  in  time,  the  white  (upper)  half  of  a  place  square  contains  a  list  of  all  resources 
currently  available  at  that  place,  and  the  gray  (lower)  half  contains  a  list  of  all  resources  currently 
in-process  at  that  place.  For  each  in-process  resource  movement  between  two  places,  a  blue  line 
is  drawn  with  a  resource  icon  placed  at  its  current  linearly  interpolated  position  between  the  two 
places,  according  to  the  schedule.  Moving  the  mouse  cursor  over  a  resource  icon  opens  a  pop¬ 
up  window  with  more  information  about  the  movement,  including  the  number  of  resources 
involved,  its  origin  and  destination,  the  activity  involved,  and  its  completion  percentage. 
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Figure  78:  Magboard 


Initially,  the  state  of  the  Magboard  reflects  the  beginning  of  the  time  horizon  (i.e.,  time  0). 
The  state  of  the  plan(s)  at  a  particular  time  can  be  displayed  by  entering  the  desired  time  in 
the  viewed  time  field  and  pressing  the  go  to  time  button  or  by  pressing  the  play  icon  button. 


Pressing  the  play  icon  button  begins  a  stepping  process  whereby  the  viewed  time  field  is  in¬ 
cremented  by  10  minutes  every  5  seconds  and  the  Magboard  display  is  updated  to  reflect  the 
incremented  time  until  the  pause  icon  button  is  pressed.  To  view  the  location  of  all  resources 
at  the  latest  calltime,  press  the  |  go  to  latest timE]  button.  The  viewed  time  field  will  be  set  to 


the  latest  calltime  and  the  Magboard  will  display  the  current  state  at  that  time. 
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Becker,  M.A.  and  Smith,  S.F. 

Mixed-Initiative  Resource  Management:  The  AMC  Barrel  Allocator 

Proceedings,  Fifth  International  Conference  on  Artificial  Intelligence  PlanningSystems  (AIPS-00), 
Brecken ridge  CO,  April  2000 

Abstract:  In  this  paper,  we  describe  the  Barrel  Allocator,  a  scheduling  tool  developed  for 
day-to-day  allocation  and  management  of  airlift  and  tanker  resources  at  the  USAF  Air  Mobility 
Command  (AMC).  The  system  utilizes  an  incremental  and  configurable  constraint-based  search 
framework  to  provide  a  range  of  automated  and  semi-automated  scheduling  capabilities,  in¬ 
cluding  generating  an  initial  solution  to  the  fleet  assignment  problem,  selective  re-optimization 
of  resource  allocations  to  incorporate  new  higher  priority  missions  while  minimizing  solution 
change,  merging  of  previously  planned  missions  to  reduce  non-productive  flying  time,  and  gen¬ 
eration  and  synchronization  of  tanker  missions  to  satisfy  air  refueling  requirements.  In  situations 
where  all  mission  requirements  cannot  be  met,  the  system  can  generate  and  compare  alternative 
constraint  relaxation  options.  The  current  version  of  Barrel  Allocator  will  go  into  operational 
use  at  AMC  as  a  module  of  Release  2.0  of  AMC’s  Consolidated  Air  Mobility  Planning  System 
(CAMPS)  in  early  2000. 


hyperlink  [Cesta,  Oddi  and  Smith,  2000b] 

Cesta,  A.,  Oddi,  A.  and  Smith,  S.F. 

Iterative  Flattening:  A  Scalable  Method  for  Solving  Multi-Capacity  Scheduling  Problems 
Proceedings,  Seventeenth  National  Conference  on  Artificial  Intelligence  (AAAI-00), 

Austin  TX,  July  2000 

Abstract:  One  challenge  for  research  in  constraint-based  scheduling  has  been  to  produce 
scalable  solution  procedures  under  fairly  general  representational  assumptions.  Quite  often, 
the  computational  burden  of  techniques  for  reasoning  about  more  complex  types  of  temporal 
and  resource  capacity  constraints  places  fairly  restrictive  limits  on  the  size  of  problems  that  can 
be  effectively  addressed.  In  this  paper,  we  focus  on  developing  a  scalable  heuristic  procedure 
to  an  extended,  multi-capacity  resource  version  of  the  job  shop  scheduling  problem  (MCJSSP). 
Our  starting  point  is  a  previously  developed  procedure  for  generating  feasible  solutions  to  more 
complex,  multi-capacity  scheduling  problems  with  maximum  time  lags.  Adaptingthis  procedure 
to  exploit  the  simpler  temporal  structure  of  MCJSSP,  we  are  able  to  produce  a  quite  efficient  so¬ 
lution  generator.  However,  the  procedure  only  indirectly  attends  to  MCJSSP’s  objective  criterion 
and  produces  sub-optimal  solutions.  To  provide  a  scalable,  optimizing  procedure,  we  propose  a 
simple,  local-search  procedure  called  iterative  flattening,  which  utilizes  the  core  solution  gener¬ 
ator  to  perform  an  extended  iterative  improvement  search.  Despite  its  simplicity,  experimental 
analysis  shows  the  iterative  improvement  search  to  be  quite  effective.  On  a  set  of  reference 
problems  ranging  in  size  from  100  to  900  activities,  the  iterative  flattening  procedure  efficiently 
and  consistently  produces  solutions  within  10%  of  computed  upper  bounds.  Overall,  the  con¬ 
cept  of  iterative  flattening  is  quite  general  and  provides  an  interesting  new  basis  for  designing 
more  sophisticated  local  search  procedures. 
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Cesta,  A.,  Oddi,  A.  and  Smith,  S.F. 

A  Constraint- Based  Method  For  Project  Scheduling  with  Time  Windows 
Journal  of  Heuristics,  vol.  8,  no.  1,  January  2002,  pp.  109-136 

Abstract:  This  paper  presents  a  heuristic  algorithm  for  solving  RCPSP/max,  the  resource 
constrained  project  scheduling  problem  with  generalized  precedence  relations.  The  algorithm 
relies,  at  its  core,  on  a  constraint  satisfaction  problem  solving  (CSP)  search  procedure,  which 
generates  a  consistent  set  of  activity  start  times  by  incrementally  removing  resource  conflicts 
from  an  otherwise  temporally  feasible  solution.  Key  to  the  effectiveness  of  the  CSP  search  pro¬ 
cedure  is  its  heuristic  strategy  for  conflict  selection.  A  conflict  sampling  method  biased  toward 
selection  of  minimal  conflict  sets  that  involve  activities  with  higher-capacity  requests  is  coupled 
with  a  non-deterministic  choice  heuristic  to  guide  the  base  conflict  resolution  process,  and  this 
CSP  search  is  embedded  within  a  larger  iterative-sampling  search  framework  to  broaden  search 
space  coverage  and  promote  solution  optimization.  The  efficacy  of  the  overall  heuristic  algo¬ 
rithm  is  demonstrated  empirically  on  a  large  set  of  previously  studied  RCPSP/max  benchmark 
problems. 


hyperlink [Cicirello  and  Smith,  2001a] 

Cicirello,  V.A.  and  Smith,  S.F. 

Wasp  Nests  for  Self-Configurable  Factories 

Proceedings,  Fifth  International  Conference  on  Autonomous  Agents  (Agents-01 ), 

Montreal  Canada,  May/June  2001 

Abstract:  Agent-based  approaches  to  manufacturing  scheduling  and  control  have  gained  in¬ 
creasing  attention  in  recent  years.  Such  approaches  are  attractive  because  they  offer  increased 
robustness  against  the  unpredictability  of  factory  operations.  But  the  specification  of  local  co¬ 
ordination  policies  that  give  rise  to  efficient  global  performance  and  effectively  adapt  to  chang¬ 
ing  circumstances  remains  an  interesting  challenge.  In  this  paper,  we  introduce  a  new  approach 
to  this  coordination  problem,  drawing  on  various  aspects  of  a  computational  model  of  how 
wasp  colonies  coordinate  individual  activities  and  allocate  tasks  to  meet  the  collective  needs 
of  the  nest.  We  focus  specifically  on  the  problem  of  configuring  machines  in  a  factory  to  best 
satisfy  (potentially  changing)  product  demands  over  time.  Our  system  models  the  set  of  jobs 
queued  in  front  of  any  given  machine  as  a  wasp  nest,  wherein  wasp-like  agents  interact  to  form 
a  social  hierarchy  and  prioritize  the  jobs  that  they  represent.  Other  wasp-like  agents  external 
to  the  nest  act  as  overall  machine  proxies,  and  use  a  model  of  wasp  task  allocation  behavior  to 
determine  which  new  jobs  should  be  accepted  into  the  machine’s  queue.  We  show  for  simple 
factories  that  our  multi-agent  system  achieves  the  desired  effect.  For  a  given  job  mix,  the  system 
converges  to  a  factory  configuration  that  maximizes  overall  performance,  and  as  the  job  mix 
changes,  the  system  quickly  adapts  to  a  new,  more  appropriate  configuration. 
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Cicirello,  V.A  and  Smith,  S.F. 

Improved  Routing  Wasps  for  Distributed  Factory  Control 

Proceedings,  IJCAI-01  Workshop  on  Al  and  Manufacturing:  New  Al  Paradigms  for  Manufacturing, 
Seattle  WA,  August  2001 

Abstract:  Agent-based  approaches  to  manufacturing  scheduling  and  control  are  attractive 
because  they  offer  increased  robustness  against  the  unpredictability  of  factory  operations.  Pre¬ 
viously,  we  introduced  a  new  approach  to  coordinating  factory  routing  and  scheduling  based  on 
a  computational  model  of  wasp  behavior.  The  natural  multi-agent  system  of  the  wasp  colony 
is  highly  effective  in  self-organizing  the  allocation  of  tasks  necessary  to  fulfill  the  needs  of  the 
nest  and  has  proven  useful  as  an  effective  model  upon  which  to  base  our  distributed  approach 
to  factory  control.  In  this  paper,  we  improve  upon  our  original  formulation  of  the  routing  wasp 
with  the  addition  of  a  tournament  of  dominance  contests  among  routing  wasps  competing  for 
the  same  job.  We  experimentally  evaluate  this  improved  performance. 

hyperlink  [Cicirello  and  Smith,  2001c] 

Cicirello,  V.A.  and  Smith,  S.F. 

Insect  Societies  and  Manufacturing 

Proceedings,  IJCAI-01  Workshop  on  Al  and  Manufacturing:  New  Al  Paradigms  for  Manufacturing, 
Seattle  WA,  August  2001 

Abstract:  In  this  paper,  we  present  examples  from  the  literature  of  successful  problem  solv¬ 
ing  systems  that  have  been  heavily  influenced  directly  from  biological  studies  of  insect  societies. 
Included  among  these  systems  are  a  few  of  our  own.  These  examples  are  presented  in  light  of 
manufacturing  applications  and  only  the  tip  of  the  iceberg  is  touched  upon.  It  is  our  hope  that 
the  reader  will  find  a  new  source  of  inspiration  in  problem  solving  tool  design;  and  realize  the 
potential  of  coordination  mechanisms  for  multi-agent  manufacturing  systems  inspired  by  social 
insects. 
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Cicirello,  V.A.  and  Smith,  S.F. 

Randomizing  Dispatch  Scheduling  Policies 

Proceedings,  AAAI  2002  Fall  Symposium  Series:  Using  Uncertainty  within  Computation, 

North  Falmouth  MA,  November  2001 

Abstract:  The  factory  is  a  complex  dynamic  environment  and  scheduling  operations  for  such 
an  environment  is  a  challenging  problem.  In  practice,  dispatch  scheduling  policies  are  com¬ 
monly  employed,  as  they  offer  an  efficient  and  robust  solution.  However,  dispatch  scheduling 
policies  are  generally  myopic,  and  as  such  they  are  susceptible  to  sub-optimal  decision-making. 
In  this  paper,  we  attempt  to  improve  upon  results  of  such  dispatch  policies  by  introducing  non¬ 
determinism  into  the  decision-making  process,  and  instead  using  a  given  policy  as  a  baseline  for 
biasing  stochastic  decisions.  We  consider  the  problem  of  weighted  tardiness  scheduling  with 
sequence-dependent  setups  with  unknown  arrival  times  in  a  dynamic  environment,  and  show 
that  randomization  of  state-of-the-art  dispatch  heuristics  for  this  problem  in  this  manner  can 
improve  performance.  Furthermore,  we  find  that  the  “easier”  the  problem,  the  less  benefit  there 
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is  from  randomization;  the  “harder”  the  problem,  the  more  benefit.  Our  method  of  randomiza¬ 
tion  is  based  on  a  model  of  the  way  colonies  of  wasps  self-organize  social  hierarchies  in  nature. 

hyperlink  [Cicirello  and  Smith,  2002a] 

Cicirello,  V.A  and  Smith,  S.F. 

Distributed  Coordination  of  Resources  via  Wasp-Like  Agents 

Proceedings,  First  International  Workshop  on  Radical  Agent  Concepts  (WRAC-2000), 

McLean  VA,  January  2002 

Abstract:  Agent-based  approaches  to  scheduling  have  gained  increasing  attention  in  recent 
years.  One  inherent  advantage  of  agent-based  approaches  is  their  tendency  for  robust  behav¬ 
ior;  since  activity  is  coordinated  via  local  interaction  protocols  and  decision  policies,  the  system 
is  insensitive  to  unpredictability  in  the  executing  environment.  At  the  same  time,  such  “self¬ 
scheduling”  systems  presume  that  a  coherent  global  behavior  will  emerge  from  the  local  inter¬ 
actions  of  individual  agents,  and  realizing  this  behavior  remains  a  difficult  problem.  We  draw 
on  the  adaptive  behavior  of  the  natural  multi-agent  system  of  the  wasp  colony  as  inspiration 
for  decentralized  mechanisms  for  coordinating  factory  operations.  We  compare  the  resulting 
systems  to  the  state-of-the-art  for  the  problems  examined. 

hyperlink  [Cicirello  and  Smith,  2004] 

Cicirello,  V.A.  and  Smith,  S.F. 

Wasp-like  Agents  for  Distributed  Factory  Coordination 

Journal  of  Autonomous  Agents  and  Multi-Agent  Systems,  vol.  8,  no.  3,  May  2004,  pp.  237-266 

Abstract:  Agent-based  approaches  to  manufacturing  scheduling  and  control  have  gained  in¬ 
creasing  attention  in  recent  years.  Such  approaches  are  attractive  because  they  offer  increased 
robustness  against  the  unpredictability  of  factory  operations.  But  the  specification  of  local  co¬ 
ordination  policies  that  give  rise  to  efficient  global  performance  and  effectively  adapt  to  chang¬ 
ing  circumstances  remains  an  interesting  challenge.  In  this  paper,  we  present  a  new  approach  to 
this  coordination  problem,  drawing  on  various  aspects  of  a  computational  model  of  how  wasp 
colonies  coordinate  individual  activities  and  allocate  tasks  to  meet  the  collective  needs  of  the 
nest. 

We  focus  specifically  on  the  problem  of  configuring  parallel  multi-purpose  machines  in  a 
factory  to  best  satisfy  product  demands  overtime.  Wasp-like  computational  agents  that  we  call 
routing  wasps  act  as  overall  machine  proxies.  These  agents  use  a  model  of  wasp  task  allocation 
behavior,  coupled  with  a  model  of  wasp  dominance  hierarchy  formation,  to  determine  which 
new  jobs  should  be  accepted  into  the  machine’s  queue.  If  you  view  our  system  from  a  market- 
oriented  perspective,  the  policies thatthe  routingwasps  independently adaptfortheir respective 
machines  can  be  likened  to  policies  for  deciding  when  to  bid  and  when  not  to  bid  for  arriving 
jobs. 

We  benchmark  the  performance  of  our  system  on  the  real-world  problem  of  assigning  trucks 
to  paint  booths  in  a  simulated  vehicle  paintshop.  The  objective  of  this  problem  is  to  minimize 
the  number  of  paint  color  changes  accrued  by  the  system,  assuming  no  a  priori  knowledge  of 
the  color  sequence  or  color  distribution  of  trucks  arriving  in  the  system.  We  demonstrate  that 
our  system  outperforms  the  bidding  mechanism  originally  implemented  for  the  problem  as  well 
as  another  related  adaptive  bidding  mechanism. 
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Cicirello  V.A.  and  Smith,  S.F. 

Amplification  of  Search  Performance  through  Randomization  of  Heuristics 

Proceedings,  Eighth  International  Conference  on  Principles  and  Practice  of  Constraint  Programming, 

Ithaca  NY,  September  2002 

Abstract:  Randomization  as  a  means  for  improving  search  performance  in  combinatorial 
domains  has  received  increasing  interest  in  recent  years.  In  optimization  contexts,  it  can  provide 
a  means  for  overcoming  the  deficiencies  of  available  search  heuristics  and  broadening  search  in 
productive  directions.  In  this  paper,  we  consider  the  issue  of  amplifying  the  performance  of  a 
search  heuristic  through  randomization.  We  introduce  a  general  framework  for  embedding  a 
base  heuristic  within  an  iterative  sampling  process  and  searching  a  stochastic  neighborhood  of 
the  heuristic’s  prescribed  trajectory.  In  contrast  to  previous  approaches,  which  have  used  rank¬ 
ordering  as  a  basis  for  randomization,  our  approach  instead  relies  on  assigned  heuristic  value. 
Use  of  heuristic  value  is  important  because  it  makes  it  possible  to  vary  the  level  of  stochasticity 
in  relation  to  the  discriminatory  power  of  the  heuristic  in  different  decision  contexts,  and  hence 
concentrate  search  around  those  decisions  where  the  heuristic  is  least  informative.  To  evaluate 
the  efficacy  of  the  approach,  we  apply  it  to  a  complex,  weighted-tardiness  scheduling  problem. 
Taking  a  state-of-the-art  heuristic  for  this  scheduling  problem  as  a  starting  point,  we  demon¬ 
strate  an  ability  to  consistently  and  significantly  improve  on  the  deterministic  heuristic  solution 
across  a  broad  range  of  problem  instances.  Our  approach  is  also  shown  to  consistently  outper¬ 
form  a  previously  developed,  rank-ordering  based  approach  to  randomizing  the  same  heuristic 
in  terms  of  percentage  of  improvement  obtained. 
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Cicirello,  V.A. 

Boosting  Stochastic  Problem  Solvers  Through  Online  Self-Analysis  of  Performance 
Ph.D.  Thesis,  Technical  Report  CMU-RI-TR-03-27, 

The  Robotics  Institute,  Carnegie  Mellon  University,  July  2003 

Abstract:  In  many  combinatorial  domains,  simple  stochastic  algorithms  often  exhibit  su¬ 
perior  performance  when  compared  to  highly  customized  approaches.  Many  of  these  simple 
algorithms  outperform  more  sophisticated  approaches  on  difficult  benchmark  problems;  and 
often  lead  to  better  solutions  as  the  algorithms  are  taken  out  of  the  world  of  benchmarks  and 
into  the  real-world.  Simple  stochastic  algorithms  are  often  robust,  scalable  problem  solvers. 

This  thesis  explores  methods  for  combining  sets  of  heuristics  within  a  single  stochastic  search. 
The  ability  of  stochastic  search  to  amplify  heuristics  is  often  a  key  factor  in  its  success.  Heuris¬ 
tics  are  not,  however,  infallible  and  in  most  domains  no  single  heuristic  dominates.  It  is  there¬ 
fore  desirable  to  gain  the  collective  power  of  a  set  of  heuristics;  and  to  design  a  search  control 
framework  capable  of  producing  a  hybrid  algorithm  from  component  heuristics  with  the  abil¬ 
ity  to  customize  itself  to  a  given  problem  instance.  A  primary  goal  is  to  explore  what  can  be 
learned  from  quality  distributions  of  iterative  stochastic  search  in  combinatorial  optimization 
domains;  and  to  exploit  models  of  quality  distributions  to  enhance  the  performance  of  stochas¬ 
tic  problem  solvers.  We  hypothesize  that  models  of  solution  quality  can  lead  to  effective  search 
control  mechanisms,  providing  a  general  framework  for  combining  multiple  heuristics  into  an 
enhanced  decision-making  process.  These  goals  lead  to  the  development  of  a  search  control 
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framework,  called  QD-BEACON,  that  uses  online-generated  statistical  models  of  search  per¬ 
formance  to  effectively  combine  search  heuristics.  A  prerequisite  goal  is  to  develop  a  suitable 
stochastic  sampling  algorithm  for  combinatorial  search  problems.  This  goal  leads  to  the  de¬ 
velopment  of  an  algorithm  called  VBSS  that  makes  better  use,  in  general,  of  the  discriminatory 
power  of  a  given  search  heuristic  as  compared  to  existing  sampling  approaches. 

The  search  frameworks  of  this  thesis  are  evaluated  on  combinatorial  optimization  prob¬ 
lems.  Specifically,  we  show  that:  1 )  VBSS  is  an  effective  method  for  amplifying  heuristic  perfor¬ 
mance  for  the  weighted  tardiness  sequencing  problem  with  sequence-dependent  setups;  2)  QD- 
BEACON  can  enhance  the  current  best  known  algorithm  for  weighted  tardiness  sequencing; 
and  3)  QD-BEACON  and  VBSS  together  provide  the  new  best  heuristic  algorithm  for  the  con¬ 
strained  optimization  problem  known  as  RCPSP/max. 
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An  Interactive  1  D+2D+3D  Visualization  for  Requirements  Analysis 
Journal  of  Scheduling  2004  (to  appear) 

Abstract:  In  most  practical  domains,  scheduling  is  not  a  one-shot  generative  task  of  pro¬ 
ducing  time  and  resource  assignments  for  pre-specified  sets  of  requirements  and  capabilities, 
but  an  iterative  process  of  getting  the  constraints  right.  Initial  solutions  are  developed  (at  some 
level  of  detail)  to  understand  the  feasibility  of  various  requirements  and  the  sufficiency  of  as¬ 
sumed  resources.  This  requirements  analysis  leads  to  reassessment  of  what  requirements  can 
be  reasonably  met  and  what  resources  need  to  be  made  available.  Changes  are  made  to  the 
constraints  governing  requirements  and  resource  availability,  and  eventually  a  final  schedule  is 
elaborated.  At  early  stages  of  this  user-driven  process,  seeing  a  fully  instantiated  schedule  is  less 
important  than  simply  knowing  whether  a  feasible  schedule  exists  and,  if  not,  the  approximate 
magnitude  of  the  shortfalls  for  different  resources  and  periods  of  time.  To  this  end,  solutions 
to  relaxed  versions  of  the  full  scheduling  problem  can  provide  helpful  guidance. 

In  this  paper,  we  describe  a  system  that  builds  on  this  notion  to  provide  a  direct-manipulation 
visual  interface  for  requirements  analysis  and  reconciliation.  The  interface  incorporates  a  3D 
visualization  that  identifies  resource  capacity  shortfalls  in  a  tractable  relaxed  version  of  the  prob¬ 
lem,  which  must  necessarily  also  be  shortfalls  in  the  original  problem.  Our  visualization  can  be 
contrasted  with  common  2D  scheduling  displays  such  as  Gantt  Charts  and  Closure  Graphs, 
which  are  designed  for  visualizing  complete  solutions  to  a  given  scheduling  problem  and  hence 
offer  only  indirect  support  for  identifying  inherently  over-constrained  regions  of  the  solution 
space.  Our  visualization,  alternatively,  directly  characterizes  this  underlying  constraint  space 
and  provides  a  direct  basis  for  requirements  analysis.  An  analyst  iteratively  adjusts  problem 
constraints  and  visualizes  the  resulting  (relaxed)  problem  solution  until  various  mismatches  be¬ 
tween  resource  requirements  and  resource  availability  have  been  satisfactorily  reconciled.  Once 
a  reasonable  compromise  has  been  found,  the  same  interface  can  then  be  used  to  guide  more 
detailed  scheduling. 
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Maximizing  Flexibility:  A  Retraction  Heuristic  for  Oversubscribed  Scheduling  Problems 
Proceedings,  Eighteenth  International [ Joint  Conference  on  Artificial  Intelligence  (IJCAI-03), 

Acapulco  Mexico,  August  2003 

Abstract:  In  this  paper  we  consider  the  solution  of  scheduling  problems  that  are  inherently 
over-subscribed.  In  such  problems,  there  are  always  more  tasks  to  execute  within  a  given  time 
frame  than  available  resource  capacity  will  allow,  and  hence  decisions  must  be  made  about 
which  tasks  should  be  included  in  the  schedule  and  which  should  be  excluded.  We  adopt  a  con¬ 
trolled,  iterative  repair  search  approach,  and  focus  on  improving  the  results  of  an  initial  priority- 
driven  solution  generation  procedure.  Central  to  our  approach  is  a  new  retraction  heuristic, 
termed  max-flexibility,  which  is  responsible  for  identifying  which  tasks  to  (temporarily)  retract 
from  the  schedule  for  reassignment  in  an  effort  to  incorporate  additional  tasks  into  the  sched¬ 
ule.  The  max-flexibility  heuristic  chooses  those  tasks  that  have  maximum  flexibility  for  assign¬ 
ment  within  their  feasible  windows.  We  empirically  evaluate  the  performance  of  max-flexibility 
using  problem  data  and  the  basic  scheduling  procedure  from  a  fielded  airlift  mission  scheduling 
application.  We  show  that  it  produces  better  improvement  results  than  two  contention-based 
retraction  heuristics,  including  a  variant  of  min-conflicts  [Minton  et.al]  with  significantly  less 
search  and  computational  cost. 
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(COSOLV 2003), 

Kinsale,  County  Cork,  Ireland,  September  2003 

Abstract:  Recent  work  has  shown  the  promise  in  using  local-search  “probes”  as  a  basis  for 
directing  a  backtracking-based  refinement  search.  In  this  approach,  the  decision  about  the  next 
refinement  step  is  based  on  an  interposed  phase  of  constructing  a  complete  (but  not  necessarily 
feasible)  variable  assignment.  This  assignment  is  then  used  to  decide  on  which  refinement  to 
take,  i.e.,  as  a  kind  ofvariable-  and  value-ordering  strategy. 

In  this  paper,  we  further  investigate  this  hybrid  search  approach.  First,  we  evaluate  meth¬ 
ods  for  improving  probe-based  guidance,  by  basing  refinement  decisions  not  only  on  the  final 
assignment  of  the  probe-construction  phase  but  also  on  information  gathered  during  the  probe- 
construction  process.  Second,  we  consider  the  relative  strengths  of  probe-based  search  control 
and  search  control  that  is  biased  by  more  classically  motivated  variable-  and  value-ordering 
heuristics  (incorporating  domain-specific  knowledge).  The  approaches  are  evaluated  on  vari¬ 
ous  problems  from  the  job-shop  scheduling  domain. 

Our  results  indicate  that  —  while  probe-based  search  performs  better  than  an  uninformed 
search  —  use  of  domain-specific  knowledge  proves  to  be  a  much  more  effective  basis  for  search 
control  than  information  about  constraint  interactions  that  is  gained  by  local-search  probes, 
and  leads  to  substantially  better  performance. 


135 


hyperlink  [Smith,  200S] 


Smith,  S.F. 

Is  Scheduling  a  Solved  Problem? 
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Nottingham  UK,  September  2003 

(An  earlier  version  of  this  paper  appeared  in  Proceedings,  CECCO  2001  Workshop  on  the  Next  Ten 
Years  of  Scheduling  Research,  San  Francisco  CA,  July  2001 .) 

Abstract:  In  recent  years,  scheduling  research  has  had  an  increasing  impact  on  practical 
problems,  and  a  range  of  scheduling  techniques  have  made  their  way  into  real-world  applica¬ 
tion  development.  Constraint-based  models  now  couple  rich  representational  flexibility  with 
highly  scalable  constraint  management  and  search  procedures.  Similarly,  mathematical  pro¬ 
gramming  tools  are  now  capable  of  addressing  problems  of  unprecedented  scale,  and  meta¬ 
heuristics  provide  robust  capabilities  for  schedule  optimization.  With  these  mounting  successes 
and  advances,  it  might  be  tempting  to  conclude  that  the  chief  technical  hurdles  underlying  the 
scheduling  problem  have  been  overcome.  However,  such  a  conclusion  (at  best)  presumes  a 
rather  narrow  and  specialized  interpretation  of  scheduling,  and  (at  worst)  ignores  much  of  the 
process  and  broader  context  of  scheduling  in  most  practical  environments.  In  this  note,  I  argue 
against  this  conclusion  and  outline  several  outstanding  challenges  for  scheduling  research. 
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Abstract:  Efficient  allocation  of  aircraft  and  aircrews  to  transportation  missions  is  an  im¬ 
portant  priority  at  the  USAF  Air  Mobility  Command  (AMC),  where  airlift  demand  must  in¬ 
creasingly  be  met  with  less  capacity  and  at  lower  cost.  In  addition  to  presenting  a  formidable 
optimization  problem,  the  AMC  resource  management  problem  is  complicated  by  the  fact  that 
it  is  situated  in  a  continuously  executing  environment.  Mission  requests  are  received  (and  must 
be  acted  upon)  incrementally,  and,  once  allocation  decisions  have  been  communicated  to  the 
executing  agents,  subsequent  opportunities  for  optimizing  resource  usage  must  be  balanced 
against  the  cost  of  solution  change.  In  this  paper,  we  describe  the  technical  approach  taken  to 
this  problem  in  the  AMC  Barrel  Allocator,  a  scheduling  tool  developed  to  address  this  problem 
and  provide  support  for  day-to-day  allocation  and  management  of  AMC  resources.  The  system 
utilizes  incremental  and  configurable  constraint-based  search  procedures  to  provide  a  range  of 
automated  and  semi-automated  scheduling  capabilities.  Most  basically,  the  system  provides 
an  efficient  solution  to  the  fleet  scheduling  problem.  More  importantly  to  continuous  opera¬ 
tions,  it  also  provides  techniques  for  selectively  re-optimizing  to  accommodate  higher  priority 
missions  while  minimizing  disruption  to  most  previously  scheduled  missions,  and  for  selectively 
“merging”  previously  planned  missions  to  minimize  non-productive  flying  time.  In  situations 
where  all  mission  requirements  cannot  be  met,  the  system  can  generate  and  compare  alterna- 
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tive  constraint  relaxation  options.  The  Barrel  Allocator  technology  is  currently  transitioning  into 
operational  use  within  AMC’s  Tanker/Airlift  Control  Center  (TACC).  A  version  of  the  Barrel  Al¬ 
locator  supporting  airlift  allocation  was  first  incorporated  as  an  experimental  module  of  the 
AMC’s  Consolidated  Air  Mobility  Planning  System  (CAMPS)  in  September  2000.  In  May  2003, 
a  new  tanker  allocation  module  is  scheduled  for  initial  operational  release  to  users  as  part  of 
CAMPS  Release  5.4. 
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Abstract:  In  this  paper,  we  describe  Comirem,  a  light-weight,  interactive  tool  for  resource 
management  in  continuous  planning  domains.  Comirem  is  designed  for  domains  where  com¬ 
plex,  heterogeneous  sets  of  resources  are  required  to  execute  planned  activities  and  usage  must 
be  synchronized  to  satisfy  complex  temporal  and  spatial  constraints.  Comirem  promotes  an 
opportunistic  planning  paradigm,  where  resource  allocation  decisions  are  made  and  revised 
incrementally  as  plans  and  availability  constraints  become  known  and  refined  during  the  plan¬ 
ning  process,  and  as  execution  deviates  from  planned  behavior.  To  this  end,  resources  are  as¬ 
signed  (and  re-assigned)  via  a  least-commitment,  constraint-postingscheduling  procedure.  The 
Comirem  system  design  follows  three  basic  mixed-initiative  principles:  (1)  that  users  will  want 
to  make  planning  and  resource  allocation  decisions  at  different  levels  of  detail  in  different  cir¬ 
cumstances  and  correspondingly  delegate  more  or  less  decision-making  responsibility  to  system 
processes  in  different  contexts,  (2)  that  abstract  domain  models,  coupled  with  graphical  visu¬ 
alization  can  provide  an  effective  basis  for  communicating  decision  impact  and  proposing  deci¬ 
sion  options,  and  (3)  that  incremental,  adaptive  problem-solving  capabilities,  which  attempt  to 
localize  change  whenever  possible  and  appropriate,  are  central  to  maintaining  continuity  in  the 
planning  and  resource  management  process.  These  principles  are  used  to  provide  a  variety  of 
tools  for  mixed-initiative  resource  allocation,  feasibility  checking,  resource  tracking  and  conflict 
resolution. 
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Abstract:  This  paper  introduces  COMIREM  (Continuous,  Mixed-Initiative  Resource  Man¬ 
agement),  a  system  for  collaborative,  incremental  development  of  plans  and  schedules  in  dy¬ 
namic,  resource-constrained  domains.  COMIREM  is  designed  to  provide  web-based  planning 
and  scheduling  services  and  is  capable  of  interacting  with  a  variety  of  interfacing  and  visual¬ 
ization  tools  using  a  standard  Internet  browser.  The  objective  is  to  deliver  a  wide  range  of 
mixed-initiative  problem-solving  capabilities  (e.g.,  specification  of  activities  and  requirements, 
commitment/de-commitmentof  resources,  manipulation  of  problem  constraints)  through  light- 
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weight  plug-in  applications  that  can  be  selected  according  to  present  circumstances.  We  present 
a  summary  of  the  current  functionality  and  an  outline  of  the  developing  system  architecture. 
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Abstract:  When  scheduling  in  dynamic  continuous  environments,  it  is  necessary  to  integrate 
new  tasks  in  a  manner  that  reflects  their  intrinsic  importance  while  at  the  same  time  minimizing 
solution  change.  A  scheduling  strategy  that  re-computes  a  schedule  from  scratch  each  time  a 
new  task  arrives  will  tend  to  be  quite  disruptive.  Alternatively,  a  purely  non-disruptive  scheduling 
strategy  favors  tasks  that  are  already  in  the  schedule  over  new  ones,  regardless  of  respective  pri¬ 
orities.  In  this  paper,  we  consider  algorithms  that  attemptto  strike  a  middle  ground.  Like  a  basic 
non-disruptive  strategy,  the  algorithm  we  propose  emphasizes  incremental  extension/revision  of 
an  existing  schedule,  rather  than  regeneration  of  a  new  schedule  from  scratch.  However,  by  al¬ 
lowing  selective  preemption  of  currently  scheduled  tasks,  our  algorithm  also  gives  attention  to 
the  relative  importance  of  new  tasks.  We  consider  a  specific  class  of  scheduling  problems  involv¬ 
ing  the  allocation  of  cumulative  (or  multi-capacity)  resources.  We  develop  an  approach  to  pre¬ 
emption  based  on  the  concept  of  freeing  up  a  resource  area  (i.e.,  time  and  capacity  rectangle) 
comparable  to  the  resource  requirement  of  the  new  task  to  be  scheduled.  Through  experimen¬ 
tal  analysis  performed  with  a  previously  developed  system  for  air  combat  operations  scheduling, 
we  demonstrate  that  our  priority-based  preemption  algorithm  is  capable  of  producing  results 
comparable  in  solution  quality  to  those  obtained  by  regenerating  a  new  schedule  from  scratch 
with  significantly  less  disruption  to  the  current  schedule. 
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An  Efficient  Consumable  Resource  Representation  for  Scheduling 
Proceedings,  Third  International  NASA  Workshop  on  Planningand  Scheduling  for  Space, 

Houston  TX,  October  2002 

Abstract:  This  paper  proposes  a  new  capacity  representation  for  consumable  resources, 
which  uses  an  expanded  balanced  tree  as  its  data  structure.  Its  efficiency  is  analyzed  and  demon¬ 
strated  by  empirical  experiments.  Algorithms  for  the  core  operations  required  of  a  scheduling 
system  (i.e.  check  available  capacity,  allocate  capacity  and  de-allocate  capacity)  are  also  pro¬ 
vided  and  proved  to  take  O (log  n)  time  in  the  worst  case. 
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